SAP HANA Security
Create Roles and Privileges from BW System in SAP HANA
What this is all about?
Within a company you have various user groups eg Users with full access, key user authorizations or end-user authorizations limited to for example one company code or one costcenter.
With the addition of new applications like SAP Lumira creating powerful Dashboards, SAP Analytics cloud creating interactive stories from BW models and others, comes the need to get the users from the different user groups authorization to work with the new applications.
This is not done with only your existing BW authorizations. These users need a user with specific authorizations or as they are called "privileges" within SAP HANA.
This blog post explains how to create roles with privileges for SAP HANA Studio from BW for DBMS profiles in order to give the users the possibilities to see views on generated SAP HANA BW content (like calculated views generated out of new composite provider and SAP BW queries 7.4).
In order to have a SAP HANA User you can either create a user within the SAP HANA Studio or as followed create a user via the BW system.
Create SAP HANA Studio User via BW
First off, it is possible to create a SAP HANA User via BW System – Triggered in Transaction SU01 in tab DBMS to SAP HANA Studio.
Type in a DBMS User name and Password as well as choose and assign any already existing roles to the user profile. Through saving, the User will be created within SAP HANA Studio. After creation assigning new roles or changing password directly within BW is a further possibility.
Generating SAP HANA Authorizations via Transaction RS2HANA_ADMIN
Be aware the user needs authorization to open a query within BW on the same provider with the corresponding authorization-relevant info objects in order to have sufficient privileges in SAP HANA Studio.
Open up Transaction RS2HANA_ADMIN, go to “Consistency check tool” and go to Button “Generate SAP HANA Authorizations”
Another possible way to generate SAP HANA Authorizations is to execute the report: RS2HANA_AUTH_RUN within SE38.
Both open up to the same screen. Select one or more Info Providers the user would need reading/reporting access to and select one or more users who will get the authorization to this provider.
Start with “Simulation mode” for a quick check if generation will be without errors and afterwards with marking “Force generation”, generate the roles containing the necessary privileges which are needed for the selected SAP HANA Objects.
Afterwards a pop-up window shows the roles which were created and assigned to the chosen User profile.
When going back to transaction SU01 the newly created roles are already assigned within the DBMS tab for the selected users.
Furthermore you can check the created authorizations with content within Table RS2HANA_AUTH_STV.
Within this example the user has now the Roles with privileges on SAP HANA Studio for accessing the Composite Provider ZPTEX05 with authorization to Company Code 0001 as was his limitations within his authorization on BW system.
Because the user is only authorized to one Company Code he will get an authorization error when trying to access all data.
Selecting the user’s correct limitation from his newly generated privileges, data will be shown.
Now you can have a go on creating your SAP BW HANA users from BW user authorizations and roles!
Conclusion
These created roles and privileges from the users BW authorizations are essentiell for further applications like SAP Lumira Dashboards and can also be used for SAP Analyitcs cloud BW stories. With these created privileges it is possible to authorize various user groups to their respective limitations.
Although it is definitely possible to create privileges and roles for the users within the SAP HANA Studio without using the BW system, it is easier and more efficient for the IT department to create roles and privileges from existing authorizations.
Last but now least a few hints:
When going into such a project, be aware of all the authorizations you have already and do a clean-up. Old ones which are not used any longer should be deleted from the user profiles.
Keep the authorizations as simple as possible.
Some conversions are not working. If a user is authorized on a hierarchy node the hierarchy is suspended into the individual nodes while generating the new authorization. If the hierarchy is really big, this leads to errors and the privilege can not be created. Then it is necessary to think about the authorization in general.