SU24 Tips & Tricks – How more authorization for an object is better than less
The first two blogs are about fields which you should and respectively should not maintain as SU24 proposals for roles. In the 3rd blog, also those fields which you cannot maintain at all.
You will have reached 99% field value completion of your roles and have where-used-lists references to all objects in the menu. That allows you to exactly see why it is in the roles and what will happen for the user if it is not in the role. You are already in control of your authorization concept from a maintenance perspective of the roles.
As a consequence of the where-used-references in each role, you might have a multiple of “authorization instances” for the same authorization object. You might also have an authorization with all fields as * (full access) values and others with specific values. This appears at first to be redundant, but it is important!
What is the sense of this and is it necessary? If you are following this blog series from the very beginning, you came across SAP Note 113290. This SAP note gives you some great hints in that aspect.
Table of Contents
Reason 1: Elimination of composite roles:
Small single roles with manual authorization instances can lead one to believe that the requirement to display something but change something else (so the object has at least two fields) within the same job function needs two separate single roles. Hence to create a “job function” role you must use composite roles to join the single roles. This is, however, an unfortunate urban legend. Sometimes this is just used as an excuse not to maintain SU24. However, it’s even worse: not to consider the role assignments to users when building the single roles!
If roles are built via the menu and SU24 is maintained for the transactions in the menu, the single role can contain a multiple of authorization instances for the same object. They are merged if they can be but are kept apart if the field status or values should not be merged into one. This means you have single authorization instances for the AUTHORITY-CHECK to probe individually to the access control, but with composite where-used-list references within the same single role. Effectively this means fewer roles required which have no cross-references or authorization “pollination” to each other. You can make changes to the single role without any side-effects on other composite roles (because there are none). If you adjust SU24 for a transaction, then all single roles with it in the menu benefit from the adjusted authorizations.
Reason 2: Performance optimization
The AUTHORITY-CHECK statement supports performance optimized checking of access. The more precise you maintain the values in SU24, the faster the system can perform authority checks. This is because system checks the existence of the object in the user buffer first. Only then, and if it exists in some form, the system checks the field values.
Some ABAP application coding will check for full access (*) and if found, then no further checks are performed. But most checks will not be satisfied by a full access (*) and the attempt to set the return code to successful (0) will look for the exact values. Whether you have one authorization instance or 100 authorization instances in the user buffer, this makes little difference as it is selecting exactly what it is looking for and is very fast. This makes multiple authorization instances in single roles faster to check than a large number of roles with different profiles which contain parts of the object checks and in worst case ranges or masked authorization values in an attempt to reduce the number of authorization instances and not have explicit values.
Let SU24 do the work for you once you have maintained it and do not worry about multiple instances of an object in a role. They are there for a good reason.
Reason 3: Complete references via where-used-lists
One of the post-go-live pain-points in SAP authorization concepts is making changes to an authorization which is already working. This is also why composite roles are the most painful of all. A change to a single role with one composite in mind affects all other composite roles. In case you add authorization manually, then there is no clear way of telling what the sum of the impact is going to be. In practice, you often end up with more and more and smaller and smaller single role assignments directly to the users.
You can avoid this trap by maintaining SU24 so that your single roles have multiple authorization instances for the same object and all roles with that transaction in the menu refer to the same proposals. This means that if you change an authorization field by adding or removing a value, you have a complete where-used-list search to identify all transactions which are affected by it in that role. That also applies to all roles that you can verify what the effect is going to be on them.
There is no other way of doing this and if you invest in SU24 based role builds then your post-go-live support costs will be reduced, and at the same time, the quality of roles will be increased.
Reason 4: Administrate roles and authorization fields via the menu only
In an average SAP system there are about 100 thousand transaction codes. On top of that, many other “start applications” such as webdynpro applications, webservices, RFC function modules, or Fiori Applications. Potentially each of these can check any of the six thousand authorization objects available.
It is not humanly possible anymore for an authorizations administrator to know all roles, all transactions, all modern “start applications” and all objects. Also monitoring the roles becomes increasingly challenging as the number of roles increases.
As the level of maturity of SU24 proposals increases, you increasingly have the confidence in administrating the roles only via their menus and the organizational field values. This represents about 5% of the work needed to create one role. The SU24 proposals are re-usable for all roles (so you do this only once in SU24) and you can replicate the organizational fields via the XAMS Org Set Management. That allows you to perform updates centrally for multiple sets of roles.
This way you define a concept for the roles and maintain metadata for them. Therefore, you don’t need to generate and maintain fields of thousands of objects in thousands of roles via PFCG.
Conclusion
Using the tips from these first four blogs you will typically still be at 99% field completion of your roles. However, you now have a better understanding of how to make the initial investment in maintaining SU24 correctly. Additionally, you achieve performance gains and a simplification of your authorization concept to maintain. Also, you can reduce the maintenance costs and at the same time increasing the quality of your roles. More tips & tricks on how to do it will follow soon.
Previously in this series:
