Defining Roles

Before we cover roles, there are some important concepts that you should understand.

In SAP HANA Cloud, we define roles, 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 is highly recommended that you manage authorizations for users by using roles. Assigning a privilege directly to a user is not 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 is not possible to explicitly deny privileges, all privileges grant access.

  The system does not 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 appears again in another role.

• Several predefined roles exist in the SAP HANA Cloud database.

  Some of them are templates (and need to be customized), and others can be used as they are.

In the SAP HANA Cloud database, there are two ways to create roles:

• As pure run-time objects (with no source file) that are created using SQL or SAP HANA Cockpit. These 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. Thee 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 is not 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).

The .hdbrole file cannot 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 are 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 required.

A dedicated file, with extension .hdbgrants, is used to define the set of authorizations that will be given to two specific users, the Object Owner and the Application User.

The <filename>.hdbgrants file is structured into three levels:

• The name of the user-provided service

• The users to whom the privileges are granted

  There are two possible "values" for users:

  • object_owner is the technical user that owns all the objects of the container schema.

  • application_user represent the users who are bound to the application modules.

• The set of privileges granted

  The syntax of this third level is very similar to the syntax of what you find in a .hdbrole file.

Note

A single .hdbgrants file can list authorizations from more than one user-provided services.

It is essential to give the application_user a correct set of authorizations. For example, if a SELECT privilege on an external table is granted to the object_owner, this will allow the creation of a synonym for this table. But if the same SELECT privilege is not granted to the application_user, you won’t be able to display the content of the target table.