SAP authorization can be both straightforward and confusing at the same time. To make it easy to understand let’s put things this way:
The SAP ERP is composed by ABAP programs, which have access groups and access objects, so in order to successfully access the programs a user must be granted the necessary authorization objects (more details in “Trace and Definition” section). Whenever the user invokes a transaction, it will execute the necessary checks in authorization objects and will execute the program or deny it. Simple right? Not that fast… let’s now see how this can get confusing.
Imagine you are in a project with ABAP developers creating specific programs and functional consultants to implement a new SAP functionality. A lot of SAP Notes are applied, many programs and new features are added to SAP and you have to grant permissions in the best way possible while still making the system reliable and compliant. To achieve such goal, there are some things to consider, which are basically:
Security context creation/revision – With the help of key users and functional consultants, create the necessary security context.
Business rules – What each person should be doing
Trace and definition – Investigate what users need to perform their activities
Risk assessment – Is the trace accurate? Does the user really need everything identified in the trace? Is it compliant with regulations and laws?
Security context creation and revision
This is basically conceptual and yet very important. If you already have a security context defined, this is the time to review it and check whether all people involved are still suitable for the job, i.e: Key Users. If you don’t have anything and will start now, depending on the security context you design you’ll either have a lot of efforts to maintain user authorization or you can have a very simple and well defined authorization structure. This is similar to data modeling, if you don’t expend enough time on it, you’ll suffer the consequences later.
Personally, I recommend to evaluate what each individual will be doing on their daily activities in their departments and break it down and group in Roles. Once you have all the roles that user will need, create a Composite Role and assign all the roles inside this brand new composite role. By doing this you will gain flexibility when the user moves to another department, because you can simply revoke the composite role and assign a new composite role containing a subset of roles that the end user will need to perform his new activities.
Basically when this is done, you will have clearly defined what composite roles belong to what department or group of users. Write this security context as a policy and formally agree with business leaders. You can keep as simple as a spreadsheet with only the necessary information (example below).
The user groups can be created/updated in this step. You can go to transaction SU01 and select the menu Environment –> User groups –> Maintain
There you can create or maintain user groups.
Once you know the way you will handle authorization assignments based on the security context established/reviewed in the first step, it is time to sit with key users and business leaders to understand what people are doing what and start mitigating activities. For example, an finance analyst can perform a payment but cannot approve it. Who can manage master data and what specific information is necessary, i.e: create a vendor with finance details such as bank account and specific tax and rates. Basically in this step you will fill the second and third column of the sample spreadsheet (Composite Role and Roles).
To make it easier to us (tech dudes), I recommend to have a functional consultant or a high skilled key user to sit with you and the business people in order to understand and agree on how each task will be done in SAP, this will facilitate a lot the next step which is the reproduction, tracing and effectively defining authorization within SAP.
Trace and Definition
Since we now have everything clearly defined, let’s go effectively to the technical side of authorization. Remember in the beginning of this post where it was mentioned that in order to access programs, the users must have access to authorization object. To confirm this, lets go to transaction SE93 and have a look in the transaction MIRO:
Looking at the picture above, we can understand that: When the user access the transaction MIRO, the Authorization object M_RECH_WRK is checked and the user must have access to the field ACTVT=01. If all the conditions are met, the user can access the program SAPLMR1M which is the actual “MIRO”.
This check could also happen inside the ABAP code, using the keyword “AUTHORITY-CHECK”. Here is an example on how that works embedded in the ABAP code:
Okay, now it is clear how authorization checks works in SAP… but looking at every program, function, reports and etc to simply create the necessary roles would be a never ending job that nobody would do, so let’s get to the solution: tracing!
My approach here is as simple as: connect to a TEST ENVIRONMENT and grant SAP_ALL profile to that functional consultant or expert key user:
Once he connects to SAP, go to transaction ST01 and start the trace. Select Authorization Check, in the general filters, type the user account and finally hit “Trace on”
Then ask him to perform the activity needs, example: View vendor information. Once he finishes, stop the trace by hitting the button “Trace off” and then hit “Analysis”. You should now select the username, authorization check and execute.
Now you have a report containing every single access the end user will need to perform the activity “View vendor information”. With the result of the trace you can create a role that can be assigned to end users.
*** The creation of the role is beyond the scope of this particular topic because it is already too big. You can go visit this post for a step by step guide on role creation***
Auditing SAP is tough and should be done on a regular basis to avoid surprises and headaches in case of external auditing. The actual auditing of the system is beyond the scope of this post because there are many ways and tools (Virsa, AIS, GRC, etc) to help with this and will vary from company to company.
To effectively perform a risk assessment, get the current scenario of who is doing what and review it with the key users. They will be able to confirm or suggest changes to access levels. If a risk is identified and cannot be treated by the system, it should be mitigated somehow… i.e, periodic audits in specific activities.
Once you have a snapshot of the current scenario, it’s time to go back to the first step and review the authorization concept and adapt the necessary changes.
Hope this post can give you a high level authorization concept for system administration. Although SAP was the system mentioned in the whole post, this concept can be easily adapted to any other systems.