How_to_set_up_standard_roles_in_SAP_HANA.pdf

SAP How-to Guide Business Analytics

SAP HANA Appliance

Richard Bremer, SAP Customer Solution Adoption (CSA)

Applicable Releases:

SAP HANA 1.0 SPS 03

Version 1.0

December 2011

How To Set Up Standard Roles in SAP HANA

Copyright 2012 SAP AG. All rights reserved. No part of this publication may be reproduced or tran smitt ed in any form or for any purpose wi thout the express p ermission of SAP AG. Th e information cont ained herein may b e changed wi thout prior notice.

Some softw are products market ed by SAP AG and its dist ributors contain propri et ary softw are component s of other software vendors. Microsoft, Windows , Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM , DB2, D B2 Universal Datab ase, Syst em i, System i5, System p, Syst em p5, Syst em x, Syst em z, System z 10, Syst e m z9, z 10, z 9, iSeries, pSeri es, xSeri es, z Series , eServer, z/VM, z /O S, i5/O S, S/390, OS/390, O S/4 00, AS/400, S/390 Parall el Enterp rise Server, Po werVM, Pow er Archit ecture, POWE R6+, PO WER6 , PO WER5 +, PO WE R5, PO WER, OpenPow er, PowerPC, Bat chPipes, Bl ad eC enter, System Storage, G PFS, H ACMP, RET AIN, D B2 Connect, RACF, Redbooks, O S/2 , Parall el Sysplex, MVS/E SA, AIX,

Intelligent Miner, WebSph ere, N etfinity, Tivoli and Informix are trademarks or regist ered trad emarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are eith er trademarks or regist ered t rad emarks of Adobe Systems In corporated in the United Stat es and /or other countries. Oracl e is a regist ered trad emark of Oracle Corporation.

UNIX, X/Op en, OSF /1, and Motif are regist ered trademarks of the Open Group.

Citrix, ICA, Program N eighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trad emarks or regist ered trad emarks of C itrix Systems, Inc.

HTML, XML, XH TML and W3C are t rad emarks or registered trademarks of W3C, World Wid e Web Consortium, M ass achus etts Institut e of Technology.

Jav a is a registered trademark of Sun Micro syst ems, Inc. Jav aScript is a registered trademark of Sun Microsyst ems, Inc., used under licen se for technology invented and i mplement ed by N etscape.

SAP, R/3, SAP N etWeaver, Duet, Partn erEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and other SAP product s and se rvices mentioned herein as w ell as thei r respective logos are trademarks or regist ered trad emarks of SAP AG in Germany and other co untries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other

Business Objects products and services mentioned herein as well as their

respective logos are trademarks or registered trademarks of Business

Objects Software Ltd. Business Objects is an SAP company. Sybase and Adapti ve Serv er, iAnywh ere, Sybas e 365, SQL Anywhere, and other Sybas e products and services mentioned herein as well as thei r respective logos are trademarks or regist ered t rad emarks of Sybase, Inc. Sybase is an SAP comp any.

All other product and service names mentioned are the trademarks of their resp ectiv e co mpani es. Dat a cont ained in this document serves information al purposes only. N ational product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may b e rep roduced, copied, or trans mitted in an y form or for any purpos e without the express prior writ ten permis sion of SAP AG.

This document is a preli minary v ersion and not subject to your licens e agreement or any other agreement with SAP. This document contains only int ended strat egies, d evelop ments , and functionalities of the SAP product and is not intended to be binding upon SAP to an y parti cular course of business , product strategy , and /or dev elopment. Pl eas e note that this docu ment is subject to ch ange and may be ch anged by SAP at any ti me without notice.

SAP assu mes no responsibility for errors or omissions in this document. SAP does not w arrant the accuracy or compl et eness of th e information, text, graphics, links , or other items contained within this mat erial . This document is provided without a warrant y of any kind, either express or i mplied, including but not limited to the i mplied w arranties of merchant ability, fitness for a particular purpose, or non-infringement.

SAP sh all hav e no liability for damages of any kind including without limit ation direct , special, indirect , or consequ ential d amages that may result from the us e of these materi als. Thi s limit ation shall not apply in cases of intent or gross negligence. The statutory liability for p ersonal injury and defectiv e products is not affected. SAP has no control over the information that you may access th rough the use of hot links contained in thes e materials and does not endors e your use of third-party Web pag es nor provide an y warranty whatso ever rel ating to third-part y Web pages .

SAP How-to Guides are intended to simplify the product implement-

tation. While specific product features and procedures typically are

explained in a practical business context, it is not implied that those

features and procedures are the only approach in solving a specific

business problem using SAP NetWeaver. Should you wish to receive

additional information, clarification or support, please refer to SAP

Consulting.

Any software coding and/or code lines / strings (Code) included in this

documentation are only examples and are not intended to be used in a

productive system environment. The Code is only intended better explain

and visualize the syntax and phrasing rules of certain coding. SAP does

not warrant the correctness and completeness of the Code given herein,

and SAP shall not be liable for errors or damages caused by the usage of

the Code, except if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java. Any code change

in these components may cause unpredictable and severe malfunctions

and is therefore expressively prohibited, as is any decompilation of these

components.

Any Java Source Code delivered with this product is only to be used by

SAPs Support Services and may not be modified or altered in any way.

Document History

Document Version Description

1.00 beta First inofficial pre-release of this guide

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly

as they appear in the

documentation.

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

Caution

Note or Important

Example

Recommendation or Tip

Table of Contents

1. Scenario .................................................................................................................................1

2. Background Information .......................................................................................................1

3. Prerequisites ..........................................................................................................................1

4. Step-by-Step Procedure ...................................................................................................... 2

4.1 Prerequisite: stored procedure wrappers ..................................................................... 2

4.1.1 Generation via SQL ............................................................................................. 3

4.1.2 Usage .................................................................................................................... 4

4.2 Data Admin Role ............................................................................................................... 4


4.2.2 Further suggested privileges ............................................................................. 6

4.2.3 Additional considerations .................................................................................. 6

4.3 Repository admin role ...................................................................................................... 7


4.3.2 Further suggested privileges ............................................................................. 8

4.3.3 Additional considerations .................................................................................. 9

4.4 User Admin Role ............................................................................................................... 9


4.4.2 Further suggested privileges ............................................................................ 11

4.4.3 Additional considerations ................................................................................. 11

4.5 Maintain Analytic Privileges roles .................................................................................. 11

4.5.1 Generation via SQL ............................................................................................ 11

4.5.2 Further suggested privileges ............................................................................13

4.5.3 Additional considerations .................................................................................13

4.6 Modeling role ...................................................................................................................13

4.6.1 Generation via SQL ............................................................................................13

4.6.2 Further suggested privileges ............................................................................15

4.6.3 Additional considerations ................................................................................ 16

4.6.4 Differences to pre-delivered MODELING role ................................................ 16

4.7 Information consumer roles .......................................................................................... 16

4.7.1 Generation via SQL ........................................................................................... 16

4.7.2 Further suggested privileges ............................................................................ 17

4.7.3 Additional considerations ................................................................................. 17

4.8 Backup Admin Role ........................................................................................................ 18


4.8.2 Further suggested privileges ........................................................................... 18

4.9 Support User Role .......................................................................................................... 18


4.9.2 Additional Considerations ................................................................................ 19


February 2012 1

1. Scenario When implementing a SAP HANA system, a security concept for SAP HANA has to be created and

implemented. Such a concept will entail groups of users with typical tasks such as database

administrators, user administrators etc. These groups of users will need individual sets of privileges

which can be bundled in roles. What particular roles are needed will depend on the set up of the

corresponding IT organization, legal requirements,

In this How-To guide we propose a set of roles that may be used as a starting point for a security

model in a SAP HANA Database system. For all roles, we explain the actions enabled by the role

(and important actions that would not be enabled), and we explain all privileges contained in the

role. All SQL Statements required in order to create the role are given as well. These statements

can be copied into an SQL editor of SAP HANA Studio to create the role directly in the database

system.

2. Background Information SAP HANA Database offers a selection of pre-installed roles for standard tasks. These roles are:

PUBLIC, MONITORING, MODELING and CONTENT_ADMIN. However, typically in a given

setup, different roles will be needed: either more granular roles, modifications to existing roles, or

additional roles.

The pre-delivered roles should therefore be considered templates or examples of those roles that

may be implemented in a given HANA system.

In a similar manner, the role templates introduced with this how-to guide should not be regarded as

final, ready-to-go roles. The privileges contained in the roles must be carefully checked against

legal requirements as well as requirements arising from security policies and project setup.

This this how-to guide does not introduce a security strategy. Considerations of how to set up a

security concept for SAP HANA will be introduced in a dedicated document.

3. Prerequisites The steps described in this how-to guide require very few prerequisites:

SAP HANA Database system of version HANA 1.0 SP 3 (revision 20 or higher)

SAP HANA Studio matching the version of SAP HANA Database

Please refer to the following sources for further information on security topics in SAP HANA

Database

The SAP HANA Database Security Guide which is available in the SAP Library at

http://help.sap.com/hana_appliance Security Information SAP HANA Security

Guides SAP HANA Database - Security Guide

The Administrators Guide for SAP HANA Database in the SAP Library at

http://help.sap.com/hana_appliance System Administration and Maintenance

Information Administrators Guide

SAP Note 1605168: SAP HANA - Handling priviledges (sic.) after upgrade to Revision 15

SAP Note 1612520: Invalidated View


February 2012 2

4. Step-by-Step Procedure In the following sub-sections, we introduce several example roles. For each role, a dedicated sub-

section Role generation via SQL lists all SQL statements required to generate the example role.

These statements can be copied out of this how-to guide and pasted into a SQL editor of SAP

HANA Studio to create and populate the role.

The roles can only be created by a sufficiently privileged database user. The pre-delivered user

SYSTEM can be used for setting up most of the roles. In exceptional cases, user SYSTEM may be

lacking individual privileges. This is mentioned in the description of the role.

4.1 Prerequisite: stored procedure wrappers ...

For granting certain privileges in a SAP HANA Database system there exist dedicated stored

procedures. The stored procedures themselves can only be invoked via prepared statements,

which makes granting these roles in the SQL Editor of SAP HANA Studio somewhat complicated.

For convenience, we suggest wrapping these stored procedures into SQLscript procedures that do

not require prepared statements.

The following table lists the privileges that require stored procedures, the name of the stored

procedure and the name of the proposed SLQscript procedure. In the table, the term activated

content refers to activated HANA data models, i.e. activated Attribute Views, Analytic Views,

Calculation Views or SQLscript procedures that have been created using the modeling component

of SAP HANA Studio.

Privilege Stored Procedure SQL Script Wrapper

grant SELECT on activated content

GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT

GRANT_SELECT_ON_VIEW

revoke SELECT on activated content

REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT

REVOKE_SELECT_ON_VIEW

grant Analytic Privilege

GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE

GRANT_ANALYTIC_PRIVILEGE

revoke Analytic Privilege

REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE

REVOKE_ANALYTIC_PRIVILEGE

Grant EXECUTE on activated content

GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT

GRANT_EXECUTE_ON_PROCEDURE

Revoke EXECUTE on activated content

REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT

REVOKE_EXECUTE_ON_PROCEDURE

sunlog6Texte surlign


February 2012 3

4.1.1 Generation via SQL The following SQL statements can be executed by a sufficiently privileged user (e.g. SYSTEM) to

generate the stored procedure wrappers. The names of the SQL Script procedures may of course

be freely chosen.

We include drop statements as well as the create statements,

drop procedure GRANT_SELECT_ON_VIEW;

create procedure

GRANT_SELECT_ON_VIEW ( in i2 varchar(256),

in i3 varchar(256) )

language sqlscript

as

begin

/* select * from dummy; */

call GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT('SELECT', :i2, :i3);

end;

drop procedure REVOKE_SELECT_ON_VIEW;

create procedure

REVOKE_SELECT_ON_VIEW ( in i2 varchar(256),


language sqlscript

as

begin


call REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT('SELECT', :i2, :i3);

end;

drop procedure GRANT_ANALYTIC_PRIVILEGE;

create procedure

GRANT_ANALYTIC_PRIVILEGE ( in i1 varchar(256),


language sqlscript

as

begin


call GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE (:i1, :i2);

end;

drop procedure REVOKE_ANALYTIC_PRIVILEGE;

create procedure

REVOKE_ANALYTIC_PRIVILEGE ( in i1 varchar(256),


language sqlscript

as

begin


call REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE (:i1, :i2);

end;

drop procedure GRANT_EXECUTE_ON_PROCEDURE;

create procedure

GRANT_EXECUTE_ON_PROCEDURE ( in i2 varchar(256),


February 2012 4


language sqlscript

as

begin


call GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT('EXECUTE', :i2, :i3);

end;

drop procedure REVOKE_EXECUTE_ON_PROCEDURE;

create procedure

REVOKE_EXECUTE_ON_PROCEDURE ( in i2 varchar(256),


language sqlscript

as

begin


call REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT('SELECT', :i2, :i3);

end;

4.1.2 Usage All stored procedure wrappers introduced above must be invoked with two parameters:

- the first parameter is the technical name of the object on which the privilege is granted (the

activated HANA data model or the activate Analytic Privilege);

- the second parameter is the name of the database user or role to which the privilege is

being granted.

The technical name of a HANA data model is

_SYS_BIC./

where the double-quotes around / are essential.

The technical name of an activated Analytic Privilege is

/

and again the double quotes are essential.

The following examples show how one can invoke the stored procedure wrappers to grant the

SELECT privilege on view test_view of package sap.test and to grant the Analytic Privilege

see_org_unit_1000 from the same package to a role named TEST_ROLE_1:

/* give access to the consumption column view */

call GRANT_SELECT_ON_VIEW ('_SYS_BIC."sap.test/test_view"',

'TEST_ROLE_1');

/* grant the Analytic Privilege */

call GRANT_ANALYTIC_PRIVILEGE ('"sap.test/see_org_unit_1000"',

'TEST_ROLE_1');

4.2 Data Admin Role ...

s

The purpose of the Data Admin Role is to

Have a single user (or group of users) that has admin access to all application tables in the

HANA Database System and which is not the SYSTEM user (note: you may not want to have

such an account in a given system);


February 2012 5

Have a database user that is able to grant privileges on all application data to other users if

required

Have a database user that can create new application schemas or objects within these

schemas

Have a database user that is able to export tables to the file system of the SAP HANA

Database server and to import tables from the file system of the SAP HANA Database server

(e.g. in the course of SAP customer messages).

Have a database user that has important privileges on the database schemas of the modeler

application (_SYS_BIC and _SYS_BI) and can grant these privileges to other users or roles.

4.2.1 Generation via SQL /* note: the drop role statement has side effects */

/* such as cascaded revoking of privileges */

drop role DATA_ADMIN_ROLE;

create role DATA_ADMIN_ROLE;

/*

If there are tables in schema system, someone must be able to at least

grant access to those tables

Note: normally this should not be required. Application data do not

belong into schema SYSTEM.

*/

grant select on schema SYSTEM to DATA_ADMIN_ROLE with grant option;

/*

All required permissions on _SYS_BIC

*/

grant select on schema _SYS_BIC to DATA_ADMIN_ROLE with grant option;

grant create any on schema _SYS_BIC to DATA_ADMIN_ROLE with grant option;

grant drop on schema _SYS_BIC to DATA_ADMIN_ROLE with grant option;

/*

All required permissions on _SYS_BI

*/

grant select on schema _SYS_BI to DATA_ADMIN_ROLE with grant option;

grant insert on schema _SYS_BI to DATA_ADMIN_ROLE with grant option;

grant update on schema _SYS_BI to DATA_ADMIN_ROLE with grant option;

grant delete on schema _SYS_BI to DATA_ADMIN_ROLE with grant option;

/*

Allow creating of new Schemas

(System Privilege)

*/

grant CREATE SCHEMA to DATA_ADMIN_ROLE;

/*

Allow binary import of tables

(System Privilege)

*/

grant IMPORT to DATA_ADMIN_ROLE;

/*

Allow binary export of tables

(System Privilege)

*/

grant EXPORT to DATA_ADMIN_ROLE;


February 2012 6

4.2.2 Further suggested privileges Whenever data schemas are created to store application data, the data admin role should be

extended with all privileges on these data schemas.

Schemas that data is loaded into via Data Services may be created by data administrators

(i.e. by users with the data admin role). The user who created that schema should then grant

all privileges on the data schema to the data admin role (including GRANT OPTION, so that

anyone with the data admin role can pass on privileges on the data schema if required.

Schemas created for real time data provisioning via SLT are treated in a special way security

wise:

SLT creates a database user in SAP HANA Database whose (randomized) password is not

known to any natural person. The only logon-enabled user in SAP HANA Database who has

any SQL privileges on the SLT data schema is user SYSTEM. This user does not have the

GRANT OPTION for the privileges, i.e. SYSTEM is not allowed to grant any privilege on the

SLT data schema to any other user or role in SAP HANA.

SAP HANA SPS 3 introduces new possibilities for granting privileges on the SLT data

schema, compared to SAP HANA SPS 2:

In SAP HANA SPS 2 there exists no generically recommendable way in which to grant

privileges on the SLT data schema to other users. If you need to do that (see

Important Notes), please contact SAP Support via an SAP Customer Message on

component BC-HAN-LTR

In SPA HANA SPS 3 (SLT version DMIS SP 5), the SLT application creates a role in

SAP HANA Database named _power_user. This role contains all SQL

privileges on the SLT data schema (without grant option). The role should be used

with extreme care and should not be given to developers (people who create data

models), because it allows the user to issue DDL and DML statements (drop, create,

insert, update, delete) on the SLT replicated data. This is a major security risk.

In addition, in SAP HANA SPS 3 / SLT DMIS SP 5, there exist stored procedures that

allow granting individual privileges on the SLT-replicated tables. Using these stored

procedures, one can grant for example grant the SELECT privilege on the replicated

tables to a modeler role. As of December 23rd 2011, there is a bug in the stored

procedure (or a related sequence) which makes the procedure not useable under

some circumstances. This should be fixed with SAP HANA Revision 23 or 24.

For the new security handling for SLT in SAP HANA SPS 3 / DMIS SP 5, see the SAP

HANA Security Guide - Trigger-Based Replication (SLT) on

http://help.sap.com/hana_appliance#section3.

4.2.3 Additional considerations It may not always be desired to have an administrative user that has all SQL privileges on all

application data schemas. It may, for example, only be acceptable to have administrative users with

SELECT and EXECUTE privileges, but not with any DML or DDL related privileges on the data

schema. The data admin role can trivially be modified for such requirements.

SELECT privilege required for activating data models

Any SAP HANA Database user that needs to activate data models (i.e. activate Attribute Views,

Analytic Views, Calculation Views or Procedures created with the modeling component of SAP

HANA Studio) needs the SELECT privilege on all tables referenced in the data model. It is therefore

necessary to grant these privileges to a modeler role and it can make system/role/user

administration easier to collect all relevant SQL privileges (including grant option) in one role.


February 2012 7

Since data replicated via SLT will typically be used in SAP HANA data models (or in direct access

through a relational Universe in SAP BusinessObjects), it will in most cases be necessary to grant

access to the SLT data schema to other database users. As mentioned in 4.2.2, this is not trivial in

SAP HANA SPS 2.

Privileges for _SYS_REPO

It should be noted that the modeler application requires that the technical database user

_SYS_REPO has the SQL SELECT privilege on all tables used within data models including the grant

option; and also the SQL EXECUTE privilege on all procedures called from within Calculation Views

or other procedures including the grant option. A data administrator should therefore, after

creating a database schema for application data, grant the SELECT privilege on that data schema

including grant option to user _SYS_REPO.

Privileges on modeler schemas

The SQL privileges on schemas _SYS_BI and _SYS_BIC have been added to the data admin role

including grant option, purely for the purpose of having at least one user in the system with these

privileges which is not the SYSTEM user. Whether or not this is actually desired can be debated.

4.3 Repository admin role The purpose of the repository admin role is to have a user or a group of users that can set up the

repository initially so that

Data models can be created and organized into a meaningful package structure

Data models can be imported/exported from/to server side. Relevant e.g. for SAP delivered

content or as a means to transport data models between several SAP HANA Systems



drop role REPO_ADMIN_ROLE;

create role REPO_ADMIN_ROLE;

/*

Allow expanding repository tree

May be granted including "grant option" if repository admins are

supposed to pass on this privilege to others users or roles.

(SQL-Privilege)

*/

grant execute on REPOSITORY_REST to REPO_ADMIN_ROLE;

/*

allow reading metadata in the system

(System Privilege)

*/

grant CATALOG READ to REPO_ADMIN_ROLE;

/*

Allow server-side export

Add ADMIN OPTION if the privilege shall be

grantable to others

(System Privilege)

*/

grant REPO.EXPORT to REPO_ADMIN_ROLE;

/*


February 2012 8

Allow server-side import

Aadd ADMIN OPTION if the privilege shall be

grantable to others

(System Privilege)

*/

grant REPO.IMPORT to REPO_ADMIN_ROLE;

/*

Allow creating etc of Delivery Units

(can be required for server-side export/import)

(System Privilege)

*/

grant REPO.MAINTAIN_DELIVERY_UNITS to REPO_ADMIN_ROLE;

/************************************************************/

/* Note on granting package privileges */

/* You may choose to grant such privileges not on the root */

/* node of the repository but rather on the master node of */

/* some sub-hierarchy of packages. */

/* In this case, you would create one role like this per */

/* sub-hierarchy of packages. */

/* Package privileges are valid for the given package and */

/* all sub-packages */

/*

Grant all package privileges on all kinds of packages

(native and imported) on all packages in the system

(on the root-note of the repository)

May be granted including "grant option" if repository admins are

supposed to pass on package privileges to others users or roles.

(Package Privilege)

*/

/* for native packages */

grant REPO.READ on ".REPO_PACKAGE_ROOT" to REPO_ADMIN_ROLE;

grant REPO.EDIT_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT" to REPO_ADMIN_ROLE;

grant REPO.ACTIVATE_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT" to

REPO_ADMIN_ROLE;

grant REPO.MAINTAIN_NATIVE_PACKAGES on ".REPO_PACKAGE_ROOT" to

REPO_ADMIN_ROLE;

/* for imported packages */

grant REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to

REPO_ADMIN_ROLE;

grant REPO.ACTIVATE_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to

REPO_ADMIN_ROLE;

grant REPO.MAINTAIN_IMPORTED_PACKAGES on ".REPO_PACKAGE_ROOT" to

REPO_ADMIN_ROLE;

4.3.2 Further suggested privileges In the template role, the privileges on the repository are granted without grant option (SQL or

package privileges) or admin option (system privileges), and as such are not grantable to other

users. If repository admins are supposed to pass on repository-related privileges to others, the

grant or admin option must be included in the role.


February 2012 9

4.3.3 Additional considerations

Finely grained package privileges

If several groups of developers build independent data models (e.g. for different application areas),

it is advisable to create a dedicated package hierarchy for each application. If the master nodes for

the application areas are set up by a repo administrator, package privileges can be distributed to

the developers in such a way, that each group of developers is only allowed to modify or activated

data models within their own application area.

For such a setup, a repository administrator would create the master node for each application and

either grant all privileges on that node (grantable to others) to a role that is given to the user

administrators

or define two roles per application area: one for reading/editing/activating models and only

for reading the data models. Note that reading refers to the act of viewing the definition of

the data model, not reading data from the data model.

Privileges on imported packages

One should treat privileges that allow the modification of imported packages or data models very

carefully. Generally, imported packages and data models should be read-only. We therefore

commented corresponding package privileges in the above SQL code.

Edit and activate privileges

In the template role, the repository admin is equipped with edit and activate privileges on the

repository tree. It should be considered carefully whether these privileges are in fact required here:

Edit: this will normally not be needed and should not be granted to a purely technical

administrative user account. A repository administrator should not need to and may not be

allowed to edit data models or Analytic Privileges.

Activate: this may or may not be needed.

o If the repository admin shall activate data models in the course of an import from

server-side, he or she will need this privilege. At the same time, activation will fail

unless the user also has certain privileges on schema _SYS_BIC and the select

privilege on all underlying database tables plus system privilege CREATE

SCENARIO. If the the repository admin is a purely technical administrative user, she

or he should not have such privileges

o If the repository admin does not have all of the SQL and system privileges required

in order to activate data models, the package privilege does not influence the list of

taks the repository admin can fulfill.

4.4 User Admin Role The purpose of the user admin role is to enable database users to

Create user accounts

Grant necessary privileges to database users

Create roles and populate them with corresponding privileges



drop role USER_ADMIN_ROLE;

create role USER_ADMIN_ROLE;


February 2012 10

/* Allows to do: */

/* - CREATE USER */

/* - DROP USER */

/* - See list of roles in Studio -> Catalog */

/* without this, you only see the role assigned to you */

/* And no, role admin is not sufficient for that. */

/* (System Privilege) */

grant user admin TO USER_ADMIN_ROLE;

/* Allows to do: */

/* - Create roles in the system */

/* - Drop roles in the system */

/* - Grant any role in the system */


grant role admin to USER_ADMIN_ROLE;

/* Stored procedures for granting Analytic Privileges and individual */

/* consumption column views */

/* (SQL Privileges) */

grant execute on GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT to USER_ADMIN_ROLE

with grant option;

grant execute on REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT to USER_ADMIN_ROLE

with grant option;

grant execute on GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE to USER_ADMIN_ROLE

with grant option;

grant execute on REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE to USER_ADMIN_ROLE

with grant option;

/* The above stored procedures cannot be invoked directly from the */

/* SQL Editor. Therefore we created wrapper functions. */

/* Note: at this point in time, Analytic Privileges do not yet belong */

/* to _SYS_REPO -> the GRANT_ACTIVATED_ANALYTIC_PRIVILEGE is */

/* not needed at the moment. */

/* (SQL Privileges) */

grant execute on SYSTEM.GRANT_SELECT_ON_VIEW to USER_ADMIN_ROLE with grant

option;

grant execute on SYSTEM.REVOKE_SELECT_ON_VIEW to USER_ADMIN_ROLE with grant

option;

grant execute on SYSTEM.GRANT_ANALYTIC_PRIVILEGE to USER_ADMIN_ROLE with

grant option;

grant execute on SYSTEM.REVOKE_ANALYTIC_PRIVILEGE to USER_ADMIN_ROLE with

grant option;

/* required for reading from PUBLIC.GRANTED_PRIVILEGES */


grant catalog read to USER_ADMIN_ROLE;

/* if user admins are supposed to grant system privileges to roles */

/* the corresponding system privileges have to be given to the */

/* user admin role with admin option */


February 2012 11

4.4.2 Further suggested privileges If user administrators are supposed to create new roles for end users such as application-specific

modeling roles the corresponding privileges must be given to the user administrators. Examples

include:

For activating data models, the SELECT privilege on all underlying tables is required. User

admins thus may need the SELECT privilege on newly created data schemas including

grant option;

Alternatively, the owner of the data schema (data admin) may have packaged the

necessary SQL privileges into individual roles. The user admins would then not need to have

these roles in order to pass them on (because they have the ROLE ADMIN system

privilege).

The same consideration applies to package privileges on newly created package hierarchies

as outlined in section 4.3.3.

If user admins create new roles that contain system privileges, these system privileges will

need to be granted to the user admins including the ADMIN OPTION. In this case, one could

create a role that contains all such system privileges including the admin option. This role

may not contain all available system privileges. For example, user admin and role admin will

probably be excluded from that role.

The same consideration as for system privileges applies for privileges that are similar to

system privileges, e.g.

o execute on REPOSITORY_REST

As is described in section 4.5, the role for maintaining Analytic Privileges may be fully or

partly included in the role for user administrators.

4.4.3 Additional considerations As outlined above, the role for user administrators may be extended by privileges on database

objects created during system setup and operations (data schemas, packages).

4.5 Maintain Analytic Privileges roles The purpose of the Maintain Analytic Privileges role is to enable a group of users to

Create, edit and activate Analytic Privileges

We explicitly do not include privileges to grant or revoke activated Analytic Privileges to/from users

or roles. These privileges are listed as part of the user admin role.

By separating the roles for maintaining Analytic Privileges and for user administration, one can

separate the definition of data access privileges from the granting of such privileges if so desired.

We assume that in many cases the user administrators will also have the role to maintain Analytic

Privileges.



drop role DROP ROLE MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

drop role MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* Required to read the repository tree */

/* (expand the "content" tree). */

/* Does not allow seeing the content of */



February 2012 12

/* packages */

/* (SQL Privilege) */

grant execute on REPOSITORY_REST to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/************************************************************/

/* Note on granting package privileges */

/* You may choose to grant such privileges not on the root */

/* node of the repository but rather on the master node of */

/* some sub-hierarchy of packages. */

/* In this case, you would create one role like this per */

/* sub-hierarchy of packages. */

/* Package privileges are valid for the given package and */

/* all sub-packages */

/* Allow reading all objects in all packages */

grant REPO.READ on ".REPO_PACKAGE_ROOT" to

MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* allow creation of new packages inside of native packages */

/* (Package Privilege) */

grant REPO.MAINTAIN_NATIVE_PACKAGES on ".REPO_PACKAGE_ROOT"

to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* allow creation of new packages inside of imported packages */

/* Note: you typically do not want to grant this privilege */

/* Imported packages should be read only. */

/*

grant REPO.MAINTAIN_IMPORTED_PACKAGES on ".REPO_PACKAGE_ROOT"


*/

/* Allow saving the ana priv (required for creating a ana priv) */

/* Grant this for native packages. */


grant REPO.EDIT_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"


/* you should normally not grant this for imported packages: */

/*

grant REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT"


*/

/* Allow activating objects (e.g. Analytic Privileges */

/* in the given package and all sub-packages */

/* Grant this for all native and imported packages. */


grant REPO.ACTIVATE_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"


/* normally will be required for imported packages, too: */

grant REPO.ACTIVATE_IMPORTED_OBJECTS to ".REPO_PACKAGE_ROOT"


/* Allow the user to verify that the tables underlying the */

/* Information Models referred to in the Analytic Privilege */

/* do exist. */

/* We simply grant CATALOG READ, so the user has no SELECT */

/* Privilege on the underlying database tables */

/* Allow reading _all_ metadata in the system, but no */

/* table contents. */


February 2012 13


GRANT CATALOG READ TO MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* *************************************** */

/* Activation: */

/* */

/* Just one privilege required in addition: */

/* System Privilege */

grant CREATE STRUCTURED PRIVILEGE to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* Allow dropping and re-creation of privileges */

grant STRUCTUREDPRIVILEGE ADMIN to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

4.5.2 Further suggested privileges We explicitly do not include the privilege to grant or revoke Analytic Privileges. These privileges are

contained in the template for the user admin role.


Finely grained package privileges

In the role template above, we grant the package privileges on the root node of the repository. If

there are several nodes in the repository tree containing Analytic Privileges, and if the handling of

these Analytic Privileges shall be strictly separated, several copies of this role template can be

created and restricted to the corresponding repository nodes.

Package privileges on imported objects

We also advice to be careful with the repository privileges maintain_imported_packages and

edit_imported_objects. Normally, imported packages such as SAP-delivered content should be

read-only. This principle should also apply if server-side export is used for transporting data models

in a system landscape. For this reason, privileges that allow modifying an imported package

structure or objects within imported packages are commented in the SQL code for generating the

template role.

4.6 Modeling role The purpose of the modeling role is to create a group of users who can

Create, edit and activate data models

Optionally restricted to a sub-hierarchy of packages within the repository

Preview these data models

Which includes privileges to read the entire content of the created views



drop role MODELING_ROLE;

create role MODELING_ROLE;






February 2012 14

/* packages */


grant execute on REPOSITORY_REST to MODELING_ROLE;


grant REPO.READ on ".REPO_PACKAGE_ROOT" to MODELING_ROLE;

/* allow creation of new packages inside of native packages */


grant REPO.MAINTAIN_NATIVE_PACKAGES on ".REPO_PACKAGE_ROOT"

TO MODELING_ROLE;

/* allow creation of new packages inside of imported packages */

/* this should normally not be granted for imported package */

/*

grant REPO.MAINTAIN_IMPORTED_PACKAGES on ".REPO_PACKAGE_ROOT"

to MODELING_ROLE;

*/

/* Allow saving the ana priv (required for creating a ana priv) */

/* Grant this for native packages. */


grant REPO.EDIT_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"

TO MODELING_ROLE;

/* allow editing of objects inside of imported packages */

/* this should normally not be granted for imported package */

/*

grant REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT"

to MODELING_ROLE;

*/

/* Activate the views underneath the given package (in this case the */

/* root node of the repository */

/* Grant this for all native and imported packages. */


grant REPO.ACTIVATE_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"

to MODELING_ROLE;

grant REPO.ACTIVATE_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT"

to MODELING_ROLE;

/* Allow the user to verify that the tables underlying the */

/* Information Models referred to in the Analytic Privilege */

/* do exist. */

/* Allow reading _all_ metadata in the system, but no */

/* table contents. */


grant CATALOG READ to MODELING_ROLE;

/* For activation: need SELECT on data schema */

/* note: we include schema "SYSTEM" here as an example. */

/* the SELECT privilege should normally not be */

/* granted on the SYSTEM schema. */

/* But it _must_ be granted on all tables used in */

/* data models, so typically on all data schemas */


grant select on schema SYSTEM to MODELING_ROLE;

/* For activation of time-based Attribute Views */

/* these are based on a table in schema _SYS_BI */


February 2012 15


grant select on _SYS_BI.M_TIME_DIMENSION to MODELING_ROLE;

/* Needed to deploy the run-time objects */

/* i.e. the consumption column views */


grant create any on schema _SYS_BIC to MODELING_ROLE;

grant drop on schema _SYS_BIC to MODELING_ROLE;

/* if a SQL script calls a function, you need */

/* execute on the run-time object */

grant execute on schema _SYS_BIC to MODELING_ROLE;

/* Required for activation */


grant CREATE SCENARIO to MODELING_ROLE;

/* required for activation of Calculation Views */

/* but not needed for attribute/analyitc views: */

/* Additionally required for reading from the */

/* activated model. */


grant select on schema _SYS_BIC to MODELING_ROLE;

/* You always need some appropriate Analytic Privilege. */

/* Either create one, or grant the SAP_ALL privilege: */

/* Note: _SYS_BI_CP_ALL allows reading the content of */

/* all activated data models (in combination with */

/* SELECT on schema _SYS_BIC). */

/* (Analytic privilege) */

call GRANT_ANALYTIC_PRIVILEGE ('_SYS_BI_CP_ALL', 'MODELING_ROLE');

/* if modelers shall also be able to use front-ends */

/* such as Analysis for Office, SAP BusinesObjects */

/* Explorer or MS Excel for checking their data models, */

/* they also need SELECT privileges on the BIMC-tables */

/* in schema _SYS_BI. We blindly grant SELECT on the */

/* entire schema here, although this is strictly */

/* a little bit more than what is required. */

grant select on schema _SYS_BI to MODELING_ROLE;

4.6.2 Further suggested privileges Note that the above role template has to be adjusted to the particular setup of your SAP HANA

system:

The SELECT privilege on the SYSTEM schema should normally not be required and thus not

be granted

Instead, the SELECT privilege on all schemas containing application data used in the data

models must be given (strictly speaking: only the SELECT privilege on the database tables

underlying the data models).

In the role template, we grant package privilege on the root node of the repository. This

may not always be desired. You may instead grant package privileges on a sub-hierarchy

within the repository tree.


February 2012 16

4.6.3 Additional considerations In larger system landscapes with several (largely) independent groups of developers (modelers),

one should consider creating

One generic modeling role that contains all privileges that are globally needed for modeling

(i.e. system privileges, privileges on schemas _SYS_BI and _SYS_BIC, )

Specific roles per application area (or generally per group of developers) which contains

those privileges that are only needed by this group of developers, i.e. the SELECT privilege

on the data schema and the package privileges on the corresponding sub-hierarchy of the

package tree

and combining these roles to one overall modeling role per group of modelers.

4.6.4 Differences to pre-delivered MODELING role The MODELING_ROLE introduced in this document contains the minimal set of privileges required

to create and activate data models. The most important difference to the pre-delivered MODELING

role is that the pre-delivered role contains the privileges needed in order to activate and re-activate

Analytic Privileges. There are a few object privileges on schema _SYS_BIC contained in the pre-

delivered role that are not strictly necessary but whose existence in the role does not pose a

security thread.

Next to the separation of data modeling and handling of Analytic Privileges, the most important

reason for introducing a dedicated MODELING_ROLE via this document is to explain in detail all

privileges needed in order to build data models.

4.7 Information consumer roles The purpose of an information consumer role is to empower a user or a group of users to

read data from a selection of SAP HANA data models (Attribute Views, Analytic Views,

Calculation Views)

with (generally) row-based/Attribute-value based restrictions, i.e. a user may only be allowed

to retrieve a subset of the data within the data model

with any supported front-end (currently the front-ends from SAP BusinessObjects version 4

and MS Excel.

The information consumer role therefore contains SQL privileges on the activated data models,

Analytic Privileges, and some additional SQL privileges on metadata tables of the modeler

application (tables in schema _SYS_BI).

It should be noted that one will typically have one such role per user or group of users with identical

privileges.



drop role INFORMATION_CONSUMER_ROLE;

create role INFORMATION_CONSUMER_ROLE;

/* access all run-time objects for the views */

grant select on schema _SYS_BIC to INFORMATION_CONSUMER_ROLE;

/* Analytic Privilege giving unfiltered access to all views */

/* Note: in a real implementation, you would grant individually */


February 2012 17

/* created Analytic Privileges */

call GRANT_ANALYTIC_PRIVILEGE ('_SYS_BI_CP_ALL',

'INFORMATION_CONSUMER_ROLE');

/* Read Model Metadata (e.g. Excel/MDX; AAO; Explorer */

grant select on schema _SYS_BI to INFORMATION_CONSUMER_ROLE;

/* The following is additionally required to do Preview in Studio */

/* You may leave this out in actual end-user roles as end-users */

/* are not likely to have access to SAP HANA Studio. */

/* Allow expanding the Content tree and seeing the list of packages */

grant execute on REPOSITORY_REST to INFORMATION_CONSUMER_ROLE;

/* Allow reading individual views (i.e. the view definitions) */

grant REPO.READ on ".REPO_PACKAGE_ROOT" to INFORMATION_CONSUMER_ROLE;

/* Some older versions of SAP BusinessObjects Analysis for Office */

/* did read version info from schema _SYS_REPO */

/* Not needed in current versions of AO. */

/*

grant select on schema _SYS_REPO to INFORMATION_CONSUMER_ROLE;

*/

4.7.2 Further suggested privileges Note that older versions of SAP BusinessObjects Analysis for Office (AO) required read access to

schema _SYS_REPO for a version lookup. This is not required any more. The corresponding

privilege is therefore commented in the above role template.


Individual roles for users / groups of users

In the template above, we globally grant full access to all data models. In reality, a role for

Information Consumers will have custom designed Analytic Privileges for each user or group of

users. And there will be one dedicated role for each user or group of users.

Defining object-level restrictions

When granting read access to a data model, there are two ways to restrict the access to the object

itself:

Via SQL privileges on the activated data model, i.e. on the consumption column view in

schema _SYS_BIC (objects named _SYS_BIC./

Via Analytic Privileges, since one can only read from an activated data model, if one has in

addition to the SQL privilege also a valid Analytic Privilege for this data model.

As Analytic Privileges are the tool of creating authorizations for the modeler application, the role

template introduced here assumes that object and row-level restrictions are being implemented

using Analytic Privileges.

This requires very careful setup of the Analytic Privileges. For example, the option to have an

Analytic Privilege apply to all information models should be avoided. On the other hand, one does

not have to deal explicitly with SQL privileges in addition to Analytic Privileges.


February 2012 18

4.8 Backup Admin Role The purpose of an a backup admin role is to empower a user to

Create data backups in SAP HANA Database

Restore data backups in SAP HANA Database

A dedicated backup admin user should for example be used if database backups are scheduled

from the Linux OS as described in SAP Note 1651055.

4.8.1 Generation via SQL /*** create a role containing the necessary privileges */

/* for creating and restoring backups ***/

Create role BACKUP_ADMIN_ROLE;

/* System privilege required to create/restore backups */

grant BACKUP ADMIN to BACKUP_ADMIN_ROLE;

/* System privilege that allows reading all catalog metadata */

grant CATALOG READ to BACKUP_ADMIN_ROLE;

4.8.2 Further suggested privileges It may be desirable to grant the backup user access to backup-related statistics. Any statistics

gathered in the system views M_BACKUP_CATALOG and M_BACKUP_CATALOG_FILES is visible

with the role as stated above.

If for example the backup script from SAP Note 1651055 is being used and if the script writes

statistics output into SAP HANA Database tables that are located in a schema that is not the user

schema of the backup admin, the backup admin role should be extended to include all necessary

SQL privileges for that backup statistics output schema.

4.9 Support User Role SAP HANA Database comes with a predefined MODELING role which gives read-only access to

the catalog metadata as well as the content of HANA Statistics tables (schema _SYS_STATISTICS),

For simple support cases, this role might be sufficient. However, a somewhat more powerful role

may be desired in many cases. What exactly is needed for a given role will depend on the scenario in

which SAP HANA Database is being used. For a typical side-by-side scenario, the following

additional privileges may be required:

- Recommended: read access to the metadata of data models, i.e. privileges to open the

design-time versions of Attribute Views, Analytic Views, Calculation Views, Procedures and

Analytic Privileges

Note: the design time version of an Analytic Privilege is a sensitive object. If support users

should not be able to access these objects, the package hierarchy has to be built

appropriately and package privileges must not be given on the root node of the repository

tree

- Recommended: read access to the tables in schema _SYS_BI, i.e. the run-time metadata

for the HANA data models

- To be considered: read access to the run time versions of the data models, i.e. permission

to read data from the data models.


February 2012 19

- To be considered: read access to the tables underlying the data models, i.e. the SELECT

privilege on the application data schemas

- To be considered: privileges to see the Statistics Server configuration

- To be considered: privilege to alter the trace settings of SAP HANA Database

- Not recommended: privilege to change the system configuration of SAP HANA Database



drop role SUPPORT_ROLE;

create role SUPPORT_ROLE;

/* Include the pre-delivered monitoring role */

grant MONITORING to SUPPORT_ROLE;

/* allows starting a basic performance trace */

/* side effect: allows deleting diagnosis files */

grant trace admin to SUPPORT_ROLE;

/* allows viewing and changing the configuration */

/* of the statisticsserver via the UI. */

/* Also allows changing "trace levels" and starting */

/* SQL traces */

/* Side effect: gives write access to the database */

/* configuration */

grant inifile admin to SUPPORT_ROLE;

/**********************************************/

/* Modeling-specific privileges */




/* packages */


grant execute on REPOSITORY_REST to MODELING_ROLE;


grant REPO.READ on ".REPO_PACKAGE_ROOT" to MODELING_ROLE;

/* Read Model Metadata (e.g. Excel/MDX; AAO; Explorer */

grant select on schema _SYS_BI to INFORMATION_CONSUMER_ROLE;

/* access all run-time objects for the views */

grant select on schema _SYS_BIC to INFORMATION_CONSUMER_ROLE;

/* Analytic Privilege giving unfiltered access to all views */

call GRANT_ANALYTIC_PRIVILEGE ('_SYS_BI_CP_ALL',

'INFORMATION_CONSUMER_ROLE');

/* read access to the tables underlying the data models */

grant select on schema to SUPPORT_ROLE;

4.9.2 Additional Considerations I have not been able to figure out how to

- Enable the full performance trace including profiler trace. At the moment, this seems only

possible with the SYSTEM user account.


February 2012 20

- Enable viewing the Statistics Server configuration via the UI (Administration View Alerts

Configure Check Settings) without granting permission to modify the database

configuration.

Of course, one can see the configuration of the Statistics Server via the Configuration tab

the content of the configuration files is available read-only without the inifile admin

system privilege.

- Enable viewing trace levels via the UI (Administration View Diagnosis Files Configure

Trace without granting permission to modify the database configuration.

Again, trace levels are accessible via the configuration files.

- Enable switching on the SQL trace without granting inifile admin.

www.sap.com/contactsap

www.sdn.sap.com/irj/sdn/howtoguides

1. Scenario2. Background Information3. Prerequisites4. Step-by-Step Procedure4.1 Prerequisite: stored procedure wrappers4.1.1 Generation via SQL4.1.2 Usage

4.2 Data Admin Role4.2.1 Generation via SQL4.2.2 Further suggested privileges4.2.3 Additional considerationsSELECT privilege required for activating data modelsPrivileges for _SYS_REPOPrivileges on modeler schemas

4.3 Repository admin role4.3.1 Generation via SQL4.3.2 Further suggested privileges4.3.3 Additional considerationsFinely grained package privilegesPrivileges on imported packagesEdit and activate privileges

4.4 User Admin Role4.4.1 Generation via SQL4.4.2 Further suggested privileges4.4.3 Additional considerations

4.5 Maintain Analytic Privileges roles4.5.1 Generation via SQL4.5.2 Further suggested privileges4.5.3 Additional considerationsFinely grained package privilegesPackage privileges on imported objects

4.6 Modeling role4.6.1 Generation via SQL4.6.2 Further suggested privileges4.6.3 Additional considerations4.6.4 Differences to pre-delivered MODELING role

4.7 Information consumer roles4.7.1 Generation via SQL4.7.2 Further suggested privileges4.7.3 Additional considerationsIndividual roles for users / groups of usersDefining object-level restrictions

4.8 Backup Admin Role4.8.1 Generation via SQL4.8.2 Further suggested privileges

4.9 Support User Role4.9.1 Generation via SQL4.9.2 Additional Considerations

How_to_set_up_standard_roles_in_SAP_HANA.pdf

Documents

Transcript of How_to_set_up_standard_roles_in_SAP_HANA.pdf