SAP are committed to improvement while keeping the user experience consistent. This is especially challenging when adding functionality. Today I am taking a look at the Repository Role Editor for SPS09 and am in the process of buying a car. Isn’t it funny how when the dashboard or headlights change it gets attention but what’s under the bonnet gets neglected? SAP have committed themselves to turning this on its head by improving if not the engine its ECU while keeping the controls including the headlights the same. The thought that sprung to mind as I considered SAP FIORI over the weekend was how SAP’s commitment is to keep the user interface similar while improving functionality and performance can be easily reconciled.
This tutorial about SAP HANA Security Repository Role Editor in SPS09. It is assumed that you are using a Windows computer and have a connection as the System User to the HANA server.
DO NOT USE THE SYSTEM USER FOR PRODUCTION PURPOSES
It is good practice to create users and assign them roles with the required privileges. You should then connect with these users and then disable the System User. Below you can see the Security Administrator role which has the system privileges shown.
The justification for creating roles and assigning users to roles is the same as I remember hearing when I learned about user and groups in Windows NT. Users should be placed in groups which have permissions already assigned to them to make administration easier. The example used in the tutorial concerns a person being replaced by someone else in the company. This way it is easy to recreate a user with the same privileges and permissions.
The security guide sums this up as follows:
However, the permissions are applied to a role are markedly different to those applied to groups. As can be seen below their scale and scope have a totally different emphasis.
The changes made in the screen below are translated into SQL in the background and are executed on the HANA server directly. It must be remembered that objects belong to the user who creates them. If a user is removed from the system, the objects he created are also removed. The question the tutorial is as follows: What happens your security administrator decides to leave the company? If we delete his user account we also delete all the roles that he created. But we may not want to do that because he may have created roles for someone else. But in a production environment do we really want our security administrator to have access to all the privileges for the roles that he is creating for someone else? However, our security administrator can design a role in the development stage, save the script in SQL, bundle it with the tables view and procedures in the repository, and let a technical user at the production stage run it. In short, HANA has implemented a separation of duties at development and production stage that means the database stays secure.
As you can see in the life cycle below. The application developer uses the HANA Studio or Web IDE to create a role. The role is part of a package that sits in the repository where multiple developers can work on it after which it can be activated and run in the development system. The next stage is to export to the production repository where it can be activated there. The Security Administrator can then grant the role as run time objects to the necessary users.
Below you can see an example for system privilege so we would enter it as code and save it to the repository.
The Change under the Hood for SPS09
SAP have built the same graphical editor for runtime objects via SAP Web IDE.
The tutorial ably demonstrates how similar the Web IDE interface is to the Repository Role Editor. All this without code. This is typical of SAP at the moment. Keeping interface design familiar, reducing reliance on coding and improving performance. If only choosing and buying a car was as straight forward.
- SAP Managed Tags:
