SAP How-to Guide

Business Analytics

SAP HANA Appliance

How To Set Up Standard Roles in SAP HANA

Applicable Releases:
SAP HANA 1.0 SPS 03

Version 1.0
December 2011
 All other product and ser vice names mentioned ar e the tr ademarks 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 proprietar y to SAP. No part of this document may b e rep roduced, copied, or tr ans 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 agr eement or any other agr eement with SAP. This document contains only int ended str at 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 str ategy, and /or dev elopment. Pl eas e note that this docu ment is subject to ch ange and may be ch anged by S AP at any ti me without notice.
SAP assu mes no r esponsibility for errors or omissions in this do cument. S AP does not w arr ant the accur acy or compl et eness of the information, text, graphics, links , or other items contained within this mat erial . This document is provided without a warrant y of any kind, either expr ess or i mplied, including but not limited to the i mplied w arr anties of mer chant 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, indir ect , or consequ ential d amages that may r esult from the us e of these materi als. Thi s limit ation shall not apply in cases of intent or gross negligence.
The statutor y liability for p ersonal injur y and defectiv e products is not affected. SAP has no control over the information t hat 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 war ranty whatso ever rel ating to third-part y Web pages .

Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be r eproduced or tran smitt ed in any form or for any purpose wi thout the expr ess p er mission of SAP AG. Th e information cont ained her ein may b e changed wi thout prior notice.
Some softw ar e products mar ket ed by S AP AG and its dist ributors contain propri et ary softw ar e component s of other softwar e vend or s.
Microsoft, Windows , Exc el, Outlook, and PowerPoint ar e r egistered tr ademarks of Microsoft Corporation.
IBM , DB2, D B2 Univer sal Datab ase, Syst em i, System i5, S ystem p, S yst em p5, S yst em x , Syst em z, S ystem z 10, Syst em z9, z 10, z 9, iS eries, pS eri es, x Seri es, z Series , eSer ver , z/VM, z /O S, i5/O S, S /390, OS /390, O S/4 00, AS /400, S /390 Parall el Enterp rise Ser ver, Po wer VM, Pow er Archit ectur e, P OWE R6+ , PO WER6 , PO WER5 +, PO WE R5, PO WER, OpenPow er , PowerPC, Bat chPipes, Bl adeC enter, S ystem Stor age, G PFS, H ACMP, RET AIN, D B2 Connect, RAC F, Redbooks, O S/2 , Parall el Sysplex , MVS/E SA, AIX,
Intelligent Miner, WebSph er e, N etfinity, Tivoli and Infor mix are tr ademarks or regist er ed trad emar ks of IBM Corporation.
Linux is the registered tr ademark of Linus Torvalds in the U. S. and other countries.
SAP How-to Guides are intended to simplify the product implement-
Adobe, the Adobe logo, Acrobat, PostS cript, and Reader ar e eith er tr ademarks or regist ered t rad emar ks of Adobe S ystems In corpora ted in the United Stat es and /or other countries.
Oracl e is a regist er ed trad emar k of Oracle Corporation.
UNIX, X/Op en, OSF /1, and Motif ar e regist er ed tr ademar ks of the Open Group.

tation. While specific product features and procedures typically are

Citrix, ICA, Program N eighborhood, MetaFr ame, WinFrame, VideoFr ame, and MultiWin are tr ad emarks or regist er ed trad emar ks of C itrix Systems, Inc.
HTML, XML, XH TML and W3C are t rad emar ks or r egister ed tr ademarks of W3C, World Wid e Web Consortium, M ass achus etts Institut e of Technology.
Jav a is a r egistered tr ademark of Sun Micro syst ems, Inc.
Jav aScript is a r egistered tr ademark of Sun Microsyst ems, Inc., used under licen se for technology invented and i mplement ed by N etscape.
SAP , R/3, S AP N etWeaver, Duet, Partn erEdge, ByDesign, S AP BusinessObjects Explor er, Str eamWork, and other S AP product s and se rvices mentioned herein as w ell as thei r r espective logos are tr ademarks or regist er ed trad emar ks of SAP AG in Germany and other co untries.

Business Objects and the Business Objects logo, BusinessObjects, explained in a practical business context, it is not implied that those
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other features and procedures are the only approach in solving a specific
Business Objects products and services mentioned herein as well as their business problem using SAP NetWeaver. Should you wish to receive
respective logos are trademarks or registered trademarks of Business additional information, clarification or support, please refer to SAP
Objects Software Ltd. Business Objects is an SAP company. Consulting.
Sybase and Adapti ve S erv er , iAnywh er e, S ybas e 365, SQL Anywhere, and other S ybas e products and services mentioned herein as well as thei r respective logos are tr ademarks or regist ered t rad emar ks of Sybase, Inc. S ybase is an SAP comp any.

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 First official release of this guide

Typographic Conventions Icons
Type Style Description Icon Description
Example Text Words or characters quoted Caution
from the screen. These
include field names, screen Note or Important
titles, pushbuttons labels, Example
menu names, menu paths,
and menu options. Recommendation or Tip
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.
<Example Variable user entry. Angle
text> 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.
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.1 Generation via SQL ............................................................................................. 5
4.2.2 Further suggested privileges ............................................................................. 6
4.2.3 Additional considerations .................................................................................. 6
4.3 Repository admin role ...................................................................................................... 7
4.3.1 Generation via SQL ............................................................................................. 7
4.3.2 Further suggested privileges ............................................................................. 8
4.3.3 Additional considerations .................................................................................. 8
4.4 User Admin Role ............................................................................................................... 9
4.4.1 Generation via SQL ............................................................................................. 9
4.4.2 Further suggested privileges ........................................................................... 10
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 ............................................................................12
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 .................................................................................15
4.7 Information consumer roles ...........................................................................................15
4.7.1 Generation via SQL ........................................................................................... 16
4.7.2 Further suggested privileges ........................................................................... 16
4.7.3 Additional considerations ................................................................................. 17
How To Set Up Standard Roles in SAP HANA

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

November 2012 1
How To Set Up Standard Roles in SAP HANA

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 GRANT_PRIVILEGE_ON_ACTIVA GRANT_SELECT_ON_VIEW

on activated TED_CONTENT
content
revoke REVOKE_PRIVILEGE_ON_ACTIV REVOKE_SELECT_ON_VIEW
SELECT on ATED_CONTENT
activated
content
grant Analytic GRANT_ACTIVATED_ANALYTIC GRANT_ANALYTIC_PRIVILEGE
Privilege AL_PRIVILEGE
revoke REVOKE_ACTIVATED_ANALYTI REVOKE_ANALYTIC_PRIVILEGE
Analytic CAL_PRIVILEGE
Privilege
Grant GRANT_PRIVILEGE_ON_ACTIVA GRANT_EXECUTE_ON_PROCEDURE
EXECUTE on TED_CONTENT
activated
content
Revoke REVOKE_PRIVILEGE_ON_ACTIV REVOKE_EXECUTE_ON_PROCEDURE
EXECUTE on ATED_CONTENT
activated
content

November 2012 2
How To Set Up Standard Roles in SAP HANA

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),
in i3 varchar(256) )
language sqlscript
as
begin
/* select * from dummy; */
call REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT('SELECT', :i2, :i3);
end;

drop procedure GRANT_ANALYTIC_PRIVILEGE;

create procedure
GRANT_ANALYTIC_PRIVILEGE ( in i1 varchar(256),
in i2 varchar(256) )
language sqlscript
as
begin
/* select * from dummy; */
call GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE (:i1, :i2);
end;

drop procedure REVOKE_ANALYTIC_PRIVILEGE;

create procedure
REVOKE_ANALYTIC_PRIVILEGE ( in i1 varchar(256),
in i2 varchar(256) )
language sqlscript
as
begin
/* select * from dummy; */
call REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE (:i1, :i2);
end;

drop procedure GRANT_EXECUTE_ON_PROCEDURE;

create procedure
GRANT_EXECUTE_ON_PROCEDURE ( in i2 varchar(256),

November 2012 3
How To Set Up Standard Roles in SAP HANA

in i3 varchar(256) )
language sqlscript
as
begin
/* select * from dummy; */
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),
in i3 varchar(256) )
language sqlscript
as
begin
/* select * from dummy; */
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.<package>/<view>
where the double-quotes around <package>/<view> are essential.
The technical name of an activated Analytic Privilege is
<package>/<privilege>
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);

November 2012 4
How To Set Up Standard Roles in SAP HANA

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;

November 2012 5
How To Set Up Standard Roles in SAP HANA

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: <insert version here>), the SLT application creates
a role in SAP HANA Database named <insert name of role>. This role contains all SQL
privileges on the SLT data schema including the grant option.

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.
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.

November 2012 6
How To Set Up Standard Roles in SAP HANA

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

4.3.1 Generation via SQL

/* note: the drop role statement has side effects */
/* such as cascaded revoking of privileges */
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;
/*
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;

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

November 2012 7
How To Set Up Standard Roles in SAP HANA

/* 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.

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.

November 2012 8
How To Set Up Standard Roles in SAP HANA

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

4.4.1 Generation via SQL

/* note: the drop role statement has side effects */
/* such as cascaded revoking of privileges */
drop role USER_ADMIN_ROLE;
create role USER_ADMIN_ROLE;

/* 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 */
/* (System Privilege) */
grant role admin to USER_ADMIN_ROLE;

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

November 2012 9
How To Set Up Standard Roles in SAP HANA

/* 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 */

/* (System Privilege) */
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 */

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.

November 2012 10
How To Set Up Standard Roles in SAP HANA

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.

4.5.1 Generation via SQL

/* note: the drop role statement has side effects */
/* such as cascaded revoking of 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 */
/* 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"

November 2012 11
How To Set Up Standard Roles in SAP HANA

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"
to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;
*/

/* Allow saving the ana priv (required for creating a ana priv) */
/* Grant this for native packages. */
/* (Package Privilege) */
grant REPO.EDIT_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"
to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;
/* you should normally not grant this for imported packages: */
/*
grant REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT"
to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;
*/

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

/* in the given package and all sub-packages */
/* Grant this for all native and imported packages. */
/* (Package Privilege) */
grant REPO.ACTIVATE_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT"
to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;
/* normally will be required for imported packages, too: */
grant REPO.ACTIVATE_IMPORTED_OBJECTS to ".REPO_PACKAGE_ROOT"
to MAINTAIN_ANALYTIC_PRIVILEGES_ROLE;

/* 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. */
/* (System Privilege) */
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.

November 2012 12
How To Set Up Standard Roles in SAP HANA

4.5.3 Additional considerations

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

4.6.1 Generation via SQL

/* note: the drop role statement has side effects */
/* such as cascaded revoking of privileges */
drop role MODELING_ROLE;
create role MODELING_ROLE;

/* Required to read the repository tree */

/* (expand the "content" tree). */
/* Does not allow seeing the content of */
/* packages */
/* (SQL Privilege) */
grant execute on REPOSITORY_REST to MODELING_ROLE;

/* Allow reading all objects in all packages */

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

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

/* (Package Privilege) */
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. */

November 2012 13
How To Set Up Standard Roles in SAP HANA

/* (Package Privilege) */
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. */
/* (Package Privilege) */
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. */
/* (System Privilege) */
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 */
/* (SQL Privilege) */
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 */
/* (SQL Privilege) */
grant select on _SYS_BI.M_TIME_DIMENSION to MODELING_ROLE;

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

/* i.e. the consumption column views */
/* (SQL Privilege) */
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 */

/* (System Privilege) */
grant CREATE SCENARIO to MODELING_ROLE;

/* required for activation of Calculation Views */

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

November 2012 14
How To Set Up Standard Roles in SAP HANA

/* Additionally required for reading from the */

/* activated model. */
/* (SQL Privilege) */
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 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.

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.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

November 2012 15
How To Set Up Standard Roles in SAP HANA

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.

4.7.1 Generation via SQL

/* note: the drop role statement has side effects */
/* such as cascaded revoking of 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 */
/* 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.

November 2012 16
How To Set Up Standard Roles in SAP HANA

4.7.3 Additional considerations

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.<package>/<view>
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.

November 2012 17
www.sap.com/contactsap

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