Defining Roles

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Create a design-time role

Design-Time Roles in an HDB Module

Access to the HDI database objects is performed automatically by the HDI container's technical user. If you want to provide additional users (other than the default technical user assigned to the HDI container) with access to database objects, you need to create one or more dedicated database roles and grant theses roles to the users requiring access to the database objects. Although it is technically possible to create catalog roles using either the SAP HANA Cockpit or SQL, for roles that are needed to access database objects in the container, it is recommended to define the role using a design-time file in the HDB module of your project.

The design-time files used to create roles must have the extension .hdbrole in order to be recognized as design-time role files.


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

Types of Privileges in a Design-Time Role

The .hdbroleconfig File

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.

Enabling Access to an External Schema

When your application requires access to an external schema, an administrator must define a dedicated user-provided service. A technical user is assigned to this service, and brings its own authorizations to the database objects.

As part of the security implementation in your project, it is necessary to define which of these authorizations will be granted to the different roles. For example, some users might need insert/update/delete privileges on a particular set of tables, when other users only need select privileges.


When creating calculation views, the main authorization you need is a SELECT privilege on the data sources.

The .hdbgrants File

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.

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.

Save progress to your learning plan by logging in or creating an account