Skip to Content

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:

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. chandr r

    Hello Sabin,

    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,

    Best regards,

    Chandra.

    (0) 
    1. Sabin Larranaga
      Post author

      Hi Chandra,

      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.

      Sabin

      (0) 

Leave a Reply