Native HANA Database Authorizations
When creating HANA database users and authorizations for custom-made schema structures, it is a very smart move to think ahead about how the assignments will be structured and managed.
The quick and obvious approach—simply creating users, assigning privileges, and being done with it—will cause confusion, frustration, and even despair over time. This article explains why this happens and outlines a better way forward.
Challenges of Ad-Hoc Authorization Management
So, what happens with the quick-and-dirty approach?
Imagine a scenario where the main developer dives into the system, creates schemas, and assigns access via privileges to other developers. These developers then assign the same access to additional users. Initially, everything works perfectly.
Then one developer leaves, and their user ID is deleted. Suddenly, users start reporting missing access. The main developer must step in, identify everyone affected, and manually reassign privileges.
When another developer leaves, database objects begin to disappear. After fixing that issue, the main developer also exits—and the entire system breaks down. The system administrator restores the database, and from that point on, no one dares to touch user IDs anymore. This leads to a slippery slope of poor user maintenance decisions.
Some teams choose to rebuild database structures from scratch, only to repeat the same mistakes because the underlying authorization setup remains unchanged.
All these issues stem from using native HANA access assignment options without a consistent and well-planned structure.
The Importance of a Well-Designed Role Concept
A well-designed HANA role concept provides structure and enables authorization setups to be transported between systems—such as development, quality, and production.
Creating this role concept requires effort. In HANA, database objects, access management, and user management are tightly intertwined—unlike in S/4HANA, SAP ERP, and other ABAP-based systems. As a result, role design must be part of the overall HANA database architecture, including schemas, tables, and other objects.
During the build phase, object creation and ownership must be carefully planned to avoid unwanted dependencies on individual developer user IDs.
Transitioning to Role-Based Access
Even if a role concept was not implemented initially and the HANA system relies on randomly assigned privileges, there is still a way forward.
The current authorization setup can be analysed, roles can be designed and implemented, and once a solid solution is in place, ad-hoc privilege assignments can be removed.
In conclusion, native HANA authorizations may seem daunting, but with the right approach and mindset, they do not need to be a headache.