Alex Ayers (Turnkey Consulting) and Julius Bussche (SDN Security Forum Moderator) have participated in many discussions around authorization concepts and administration in the SDN security forum, so we got together to write a joint-blog about some of the available solutions - the intention being that we could spar against each other before being flamed by the SDN community :-) This is part 1.
ABAP authorizations are nothing new to SAP... SU01 is still there, as are the user BAPI's, even SU02 still works, and the PFCG "Profile Generator" works as well... sometimes even as it was designed to work. The tools, features and even tables have changed over time; however a little gem still remains under-rated in our opinion: this series of blogs revolves around transaction SU24 - Proposed Authorization Check Indicators for PFCG, and the behaviour of authority-check statements when PFCG is activated via profile parameter auth/no_check_in_some_cases = ‘Y‘ (which is the default installation value).
Looking back to the "old days" there were no S_TCODE checks (except possibly the optional "additional" object check at transaction start - visible in transaction SE93) and authorizations were created and combined in manually created profiles. The skill of the security administrator was to work out which objects and values corresponded to which functions and data. Security was often dealt by (not) training the user. Later on we were given the S_TCODE check (later moved from the ABAP environment to the SAP kernel) to give a bit more granularity and "up front" restriction; and today we have the profile generator as a tool which has made the creation of profiles much easier.
The profile generator automatically creates the authorizations and profiles based on transaction codes and authorization object values we specify as data in the role. To help speed up this process, SAP provides a helping hand and if we enter a transaction into a role menu, SAP proposes some authorization object values which may or may not be relevant. These proposal values can range from very accurate to non-existent (as many working with S_ALR reports in the past will have experienced). Considering that the authorizations evaluated are dependent on data, configuration of the application, navigation path through transaction(s) etc, it is easy to see how the proposals can't be right 100% of the time! Perhaps the choice of transaction for the business process is not right 100% of the time either!
During an SAP implementation, it is often challenging to identify the choice of transaction codes a certain function in the organization should be able to execute; and once successfully executed, what the folks equipped with a successfully executed transaction should, or would be able to do while using and completing the transaction (and subsequent ones, or user exits).
Once we think we have done a good job, the project is live, users aren't complaining too much, the greater challenges arise (sometimes soon) afterwards: an SP or release upgrade, an audit, or perhaps business functions bring their security concerns about each other (?).
Increasingly, we are challenged when the authorizations in their respective roles become transparent to other "steakholders" via an analysis tool such as Compliance Calibrator or the SAP standard reports in transaction SUIM (e.g. RSUSR008_009_NEW) which look beyond just the name of a role; at which time changes to the roles are requested... => and the documentation of the activity, and which transaction context it originated from originally, is sometimes hard to track down. This might, case by case, be a vast understatement...
This is where transaction SU24 can become your best friend if you set it up correctly from the start and document all entry points into the system.
Image 1: An example of the check indicators for transaction SE38:
and the proposal indicator values for PFCG:
SAP delivers default generic settings for the customer SU24 settings, in transaction SU22. So that you do not have to reinvent the wheel, but rather just tune it to your requirements, these SAP defaults in SU22 are built during development of the transactions and applications based on intentions for the use of the transaction and assumptions about the choice of the transaction which the user will have, as well as defaults for certain released RFC enabled function modules, internal and external services.
In transaction SU25, you can (amongst other things in further steps) transfer the initial default settings from the SAP „owned" default values (SU22) to your implementation specific values (SU24), which can then be changed via SU24 as required. Important are the following types of „check indicator" values. Note that you should heed the warnings, and for certain objects (system critical, or HR related, etc) you cannot permit a "no check", which effectively sets sy-subrc = 0 for specific transaction sensitive context calls.
Image 2: Check indicator settings:
C = Check (if checked in the ABAP code!)
N = Do not check (even if checked directly in the ABAP code!)
"No check" indicators should be well documented (in the transaction!) so that reuse does not create unexpected additional security gaps. For optional and exceptional objects, it does generally not make sense.
Considering that a "normal" implementation (should there be such a thing) would seldom actually request the deactivation of an application specific authority-check for a transaction context... the PFCG proposals (to follow) are a second and even more useful SU24 gem which can be used.
In SU24, you have options to maintain proposals for authorizations when you add (or change) the transaction, RFC or service on the menu tab of PFCG.
Image 3: Proposal indicators:
Proposal "Yes" (or CM): If checked in the code and (independently) also will pull all maintained objects, their fields and values into the role when the transaction, function module or service is added to the „menu" tab in transaction PFCG.
Proposal "No" (or N) = Not proposed in PFCG, but will generally be checked even if not required for the transaction (often S_DEVELOP checks are found here, which are stronger than many others; hence not proposed).
Proposal ‘ ‘ (or U): Unmaintained or unknown.
(before release 7.00 these indicators were named differently, particularly so if you have the habit of looking directly at the tables).
At first, this might sound scary => adding a transaction „pulls all objects and values..." means that adding a transaction to the role menu will add ALL objects and maintained SU24 fields with values at the same time!!! OMG! That is out of control! We only wanted to add or remove a transaction and not "really" influence the ability to use it!!... :-).
If you maintain the indicators carefully and take due care in the choice of transaction, then a little miracle can happen for sustainability and maintainability of the concept.
Imagine the following scenario: Your users can execute a given set of transaction codes (object S_TCODE) and can also use the transactions with create & change activities permitted for the application specific objects, regardless of which role those authorizations come from... They can however as a result change any field or perhaps even select any document to change, which is undesirable. You then discover that there are 10 other transactions which lead to the same screens or reports, and 20 other authorizations in their roles to use the transactions with the business object values in them. So where is the link between them, considering that there might be (at least) 200 combinations possible.
The reason for this, is sometimes the choice of transaction added to object S_TCODE (or via the menu) and additionally "Manually" inserted or "Changed" authorizations / field values to use the transaction which are not reflected in the SU24 check indicators.
By doing this, the relationship between the transaction (and also function modules and services) and the application specific objects required to use it are broken (this is a very important part of the blog), and any changes required need to be maintained manually, and individually, as well. Additionally, all changes (new checks, new objects, etc) coming from SAP with SP's and release changes, are likely to cause a few surprises during testing (or go-live) as the authorizations do not have a means to see these new, changed or removed values which relate to the transactions, RFC modules or other services - so they remain, or are not updated / deleted. The intact ones can be processed in transaction SU25 (upgrade steps) which will identify and propose the changes introduced.
This situation can to a certain extent be solved by a careful choice of entry transaction (do vendor invoices need to be entered via FB01? Not...), from which the user can only navigate via selection buttons or menus etc into further transaction contexts. Maintaining the required and desired authorization objects and their field values against the entry point transactions in SU24... (and eliminating peripheral manually entered transactions from S_TCODE) is however not just master data for the sake of master data...
Here is where the gem pays off as information value:
When you want to change a number of roles for a potentially large population of users by removing a specific object or activity type field for a specific context, you can remove it once from SU24 for that transaction, function module or service identified to have introduced it. The activity related fields maintained in SU24 will adjust the authorization values in the roles (except for those which you have inserted manually or changed directly!) when you select the „read old, merge new" option in PFCG.
Image 4: Merging the new SU24 data with the existing role data (if connected to the calling transaction, RFC or service):
This can only be done in "Expert mode", which is rather misleading... because "expert mode" is dependent on the choice of transaction and how SU24 is setup in the beginning. Sometimes being an expert is too late.... so perhaps unrealistic... but bloggable none the less... (see disclaimer below).
In some special cases, for example parameter transactions and variant transactions, it is possible (and recommended) to maintain SU24 for more than just activity type fields (there are at least 30 such fields, in addition to ACTVT). Generally OrgLevel field values are tied to organizational data, such as company code (field BUKRS), which should not normally be maintained directly in SU24, but in special cases intended only for specific orgs which are not necessarily controlled by the coding, this can be done if the transaction code (or set of them) are well documented, as maintaining the SU24 indicators of the core transaction would not make sense. These are mostly generic or DUMMY checks, which are only overwritten if SU24 & Co. are maintained for the calling transaction (the parameter transaction).
Conclusion of part 1: SU24 is intended for authorization objects, and primarily activity or action related fields, which have a defined and consistent relationship with the caller, which can be maintained in SU24 and distributed to the roles based on the tcode, RFC or service context (caller), without having to maintain the authorizations manually. This also includes customer transactions and objects.
Of course, SPRO comes to mind now, and multiple authorization instances of objects in the same role, and composite roles, etc... more about that and other tweaks in part 2 and beyond.
(Disclaimer: SAP does not recommend changing the delivered SU24 settings unless you are familiar with the implementation specific business processes and what the effect of the SU24 indicators will be on the roles in those business processes. The SU22 settings should not be changed, except by SAP and introduced via Support packages and Release upgrades).
