Security Concepts
Before we cover roles, there are some important concepts that you must understand.
In SAP HANA Cloud, we define roles and users, and assign privileges. Privileges can be assigned to users directly. They can also be assigned to users indirectly by using roles.
Roles help you to structure access using reusable business-related roles. Roles can be nested, enabling the implementation of a hierarchy of roles.
It's highly recommended that you manage authorizations for users by using roles. Assigning a privilege directly to a user isn't a good practice and creates a lot of maintenance.
Some key point regarding security concepts of SAP HANA Cloud:
All the privileges granted directly or indirectly to a user are combined.
Whenever a user tries to access an object, the system performs an authorization check based on the user's roles and directly allocated privileges (if any).
It isn't possible to explicitly deny privileges. All privileges grant access.
The system doesn't need to check all the users roles. As soon as all the privileges required for a specific operation on a specific object have been found, the system ends the check and allows the operation without checking if the same privileges appear again in another role.
Several predefined roles exist in the SAP HANA Cloud database.
Some of them are templates (and must be customized), and others can be used as they are.
Defining Roles
In the SAP HANA Cloud database, there are two ways to create roles:
As pure runtime objects (with no source file) that are created using SQL or SAP HANA cockpit. These objects are called Catalog Roles. You assign privileges to these roles using SQL grant statements.
By means of source files that you create in the HDB module of a project. These are called Design-Time Roles, and the source file describes the privileges that are immediately granted when the role is deployed.
The design-time files used to create roles must have the extension .hdbrole in order to be recognized as design-time role files.
Note
Each role must be defined in its own .hdbrole design-time file.
It isn't possible to create several roles within the same .hdbrole file.
The role ID (including a valid namespace if applicable) must be unique in the HDB module, as for any other object (calculation view, synonym, and so on).
Types of Privileges in a Design-Time Role
The .hdbroleconfig File
The .hdbrole file can't contain references to real schema names, but only logical references to schemas that are resolved in another type of design-time file: the .hdbroleconfig file.
The purpose of the.hdbroleconfig file is to maintain the actual name of the external schemas in a dedicated file, instead of having many occurrences of the schema names in the .hdbrole files themselves. It makes the maintenance of a project easier when you're able to maintain the references to external schemas in just one place.
You can create the .hdbroleconfig file manually and then specify this file when you create your .hdbrole file. Or you can generate the .hdbroleconfig file automatically from within the .hdbrole editor and then optionally adjust the generated file if necessary.
Using the Role Editor
The .hdbrole and .hdbroleconfig files can be created as text files or you can use the Role Editor.
By default, when you create a new .hdbrole file, the Role Editor opens.
The following video shows how the Role Editor can be used to generate the corresponding files.
