6.7.1 Catalog Roles and Repository Roles Compared
It is possible to create roles as pure runtime objects that follow classic SQL principles or as design-time
objects in the repository of the SAP HANA database. In general, repository roles are recommended as they
offer more flexibility. For example, they can be transported between systems.
The following table summarizes the differences between catalog roles and repository roles:
Table 35:
Feature
Catalog Roles Repository Roles
Transportability Roles cannot be transported between
systems. They can only be created in
runtime by users with the system privi
lege ROLE ADMIN.
Roles can be transported between sys
tems using several transport options:
● SAP HANA Application Lifecycle
Manager
● The change and transport system
(CTS+) of the SAP NetWeaver
ABAP application server
● SAP HANA Transport Container
(HTC)
Version management
No version management is possible. The repository provides the basis for
versioning. As repository objects, roles
are stored in specific repository tables
inside the database. This eliminates the
need for an external version control
system.
Relationship to creating database user
Roles are owned by the database user
who creates them. To create a role, a
database user requires all the privi
leges being granted to the role. If any of
these privileges are revoked from the
creating user, they are automatically
revoked from the role. Similarly, if the
creating user is dropped, all roles that
he or she created are also dropped.
The technical user _SYS_REPO is the
owner of roles, not the database user
who creates them. Therefore, roles are
not directly associated with the creat
ing user. To create a role, a database
user needs only the privileges required
to work in the repository.
Grant and revoke process
Roles created in runtime are granted
directly by the database user using the
SQL GRANT and REVOKE statements.
Roles can only be revoked by the gran
tor. If the granting user is dropped (not
necessarily the role creator), all roles
that he or she granted are revoked.
Roles are granted and revoked using
built-in procedures. Any administrator
with the EXECUTE privilege on these
can grant and revoke roles. Role crea
tion is decoupled from the grant and re
voke process.
In general, it is recommended that you model roles as design-time objects for the following reasons:
● Unlike roles created in runtime, roles created as design-time objects can be transported between systems.
This is important for application development as it means that developers can model roles as part of their
application's security concept and then ship these roles or role templates with the application. Being able
to transport roles is also advantageous for modelers implementing complex access control on analytic
content. They can model roles in a test system and then transport them into a production system. This
avoids unnecessary duplication of effort.
● Roles created as design-time objects are not directly associated with a database user. They are created by
the technical user _SYS_REPO and granted through the execution of stored procedures. Any user with
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 77