How to get hit by the ABAP authorizations bus, and survive to tell the tale Part 1. 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. The RBP framework is the authorizations framework used in SuccessFactors. Before I continue it is worth mentioning that there is a legacy permissions framework in. The Trump administration on Tuesday announced the orderly wind down of the Obamaera program that gave a deportation reprieve to illegal immigrants. ABAP authorizations are nothing new to SAP SU0. BAPIs, even SU0. 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 SU2. Proposed Authorization Check Indicators for PFCG, and the behaviour of authority check statements when PFCG is activated via profile parameter authnocheckinsomecases Y which is the default installation value. Looking back to the old days there were no STCODE checks except possibly the optional additional object check at transaction start visible in transaction SE9. 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 STCODE 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 SALR reports in the past will have experienced. Considering that the authorizations evaluated are dependent on data, configuration of the application, navigation path through transactions etc, it is easy to see how the proposals cant be right 1. Perhaps the choice of transaction for the business process is not right 1. 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 arent 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. RSUSR0. 080. 09NEW 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 understatementThis is where transaction SU2. Image 1 An example of the check indicators for transaction SE3. PFCG SAP delivers default generic settings for the customer SU2. SU2. 2. So that you do not have to reinvent the wheel, but rather just tune it to your requirements, these SAP defaults in SU2. RFC enabled function modules, internal and external services. In transaction SU2. SAP owned default values SU2. SU2. 4, which can then be changed via SU2. 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 codeN Do not check even if checked directly in the ABAP codeNo 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 SU2. In SU2. 4, 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 SDEVELOP checks are found here, which are stronger than many others hence not proposed. Proposal or U Unmaintained or unknown. 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 SU2. 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 STCODE 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 1. So where is the link between them, considering that there might be at least 2. The reason for this, is sometimes the choice of transaction added to object STCODE or via the menu and additionally Manually inserted or Changed authorizations field values to use the transaction which are not reflected in the SU2. 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 SPs 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.