Best practices and recommendations for developing HDI-based roles
Developing and managing HANA database roles is one of the key activities to control what the users can do and their access to critical data in the system.
Before the arrival of SAP HANA extended application services, advance model (XSA) there were two types of roles in HANA. Catalog roles, which are created directly in the catalog and, repository roles, which are created using the HANA Repository.
With the introduction of XSA, it was also introduced a new type of roles known as HDI-based roles. Like repository roles, HDI-based roles provide role versioning and can be transported between systems.
As the HANA Repository and the SAP HANA extended application services, classic model (XSC) have been deprecated and are planned to be removed from the next major HANA release, HDI-based roles are now the recommended type of roles to be used, and thus, the successors of the repository roles.
The HDI-based roles and repository roles have fundamental differences in the way they are developed or are assigned. To explain these differences, we have prepared the Best practices and recommendations for developing roles in SAP® HANA document, where is described what are the most important changes related to role development process and to provide you additional information and recommendations on how to address the common challenges when developing HDI-based roles.
Additionally, in the document, we deliver and describe HDI-based role templates for administrative tasks in the HANA database. You can use this role templates as a starting point for the creation of their own HDI-based roles.
For further information about the deprecation of the HANA Repository and XSC, you can check:
- SAP Note 2465027 – Deprecation of SAP HANA extended application services, classic model and SAP HANA Repository (logon required)
Good to know about HDI role concept in HANA, Thanks for sharing valuable documents.
In the document you published for Best practices and recommendations for role developing for SAP HANA XSA, in chapter 6.1 you mentioned
As a principle, we should clearly differentiate security-related development, like role development, from application development. We don´t want to give application developers the possibility to create roles with privileges for database administration for example. We can avoid this by having a dedicated organization or a dedicated space within our organization for security-related development.
Will you please let me know how can we do "differentiate security-related development, like role development, from application development". do you have any document or a blog for the same, please provide the link.
How we can we organize security objects in one organization or space, is it applicable for only database roles or end user roles which are created in container can be also maintain in seperate security space.
Thanks a lot in advance,
When I refer to security-related development, I meant the creation of all your administration and security-related roles (DBA roles). Normally in your system, you will need to create a few roles that will contain powerful privileges such as SYSTEM PRIVILEGES. The recommendation is to manage all these objects in a dedicated space that should be separated from all other spaces used by application development in XSA.
Technically we cannot prevent that the developers in a space create objects like .hdbroles inside their projects, and actually, we don´t want to do that (in some cases it could make sense to manage the roles for an app in the same space where the app is deployed).
What we should control are the privileges that developers can include in the .hdbroles objects and we can do this by using different spaces.
As an example, the worst case scenario is to use one organization and one space for all the developments (Similar approach as it is with XSC and the HANA repository).
In this case, if you develop your system administration roles you will need to grant to the #OO user all the required system privileges. For this, the recommended approach is to use a User Provided Service and use the .hdbgrants file.
As the app developers work in the same space, they could take advantage of this configuration and leverage other objects resources from the space (e.g. the User Provided Service mentioned before) and potentially take advantage of them.
SAP does not provide any recommendation about the number of organization and spaces you should have in your system. This concept should give you the flexibility to adjust the system to your needs. The only recommendation is to separate in a dedicated space all the security-related development from the rest of the development activities.
I hope this clears your doubt.
When trying to access the SAP note, the page throw error messages.
You are not entitled to access SAP Note/KBA 2465027.
SAP Note 2465027 is at present released SAP internally.
link to Best Practice document https://www.sap.com/documents/2018/04/fe086f0d-fa7c-0010-87a3-c30de2ffd8ff.html seems to be outated, document can't be found.
Could you please check?
The link to the document is working correctly. can you try again?
Works fine now. Thanks!
the link to the best practice document is not working again.
Could you please update it?
What is the recommendation for transporting HDI roles created on XSA?
You can use the Change and Transport System (CTS) for transporting applications running on SAP HANA extended application services, advanced model.
Also check the "Transporting XS Advanced Applications with CTS" section from the SAP HANA Developer Guide for SAP HANA XS - Advanced Model
Hi Sabin, In case of CTS not available, xs-cli tools deployment is the only preferred approach? is there any other option available for deployment?
Currently, we only have XSA/WebIDE installed on our development system. To implement CTS and move changes accross the landscape, we would have to install XSA/WebIDE on our QA and Production Systems, correct? Is this the standard approach?