How you can leverage new functionality to improve your security role build in SAP S/4HANA.

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

For as long as I’ve been building application security roles via transaction PFCG, this is the mantra I’ve followed when maintaining authorisations. Transaction PFCG (Role Maintenance) is integrated with Transaction SU24 (Authorisations Proposals). This integration automatically imports and removes proposals from the role authorisation data based on the items in the role menu.

With the move to SAP S/4HANA and SAP Fiori, managing authorizations effectively becomes more important than ever.   Authorizations directly affect the User Experience of your users. Get it wrong and you risk actively degrading UX adoption and reduce the benefits that your users and your organization can derive from these innovations.  For example, manually adding transaction code to role will make it unavailable to users in Fiori Launchpad.

An overview of PFCG and SU24 integration

For the most part, transaction SU24 is a build accelerator and is a is considered a best practise for role build as it:

• Reduces access creep: when transactions are removed from the role menu, the associated authorisations proposals are also removed (so long as another menu item doesn’t require them). This benefit only works for standard and maintained authorisation status items.
• Reduces authorisations errors: the role will automatically receive the require authorisations for each application so long as the mappings are fully maintained in transaction SU24, and the application has been added to the role menu
• Reduces build Effort and time: the security administrators can leverage existing mappings as part of role build and requires less time to map the values out for each role.
• Simplifies and Improves Impact Analysis: it makes is easier for role authorisations experts to easily identify why an authorisation is part of a security role. This helps with segregation of duties impact assessment, role clean-up, and regression test prioritisation.

Going back to the mantra –

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

Why Avoid CHANGED?

We avoid CHANGE as it is a deliberate breaking of mappings and deviates from consistency. A CHANGED status object is treated like a MANUAL object. Transaction PFCG cannot automatically remove a CHANGED authorisation from the role when the transaction is removed as there is not relationship between the data. Therefore, CHANGED objects can increase access creep and make it difficult to properly impact assess or remove the access.

Why MANUAL by Exception?

We accept MANUAL by exceptions. Some authorisations are required but are not mapped to applications items that can be added to a role menu (e.g. S_RFCACL for trusted RFC). Some may be clear design decisions for supplementing an existing role to provide additional authorisation (e.g. purchasing approval codes). These exceptions are clearly documented and less likely to change.

Why strive for STANDARD?

We aim for STANDARD as it meant we had a 100% alignment with authorisation proposals. Assuming SU24 data is accurate, it is unlikely the security administrator team needs to maintain values in PFCG.

Why is MAINTAINED ok?

We accept and settle for MAINTAINED as a balance between mapping what we can in SU24 and avoiding CHANGED status.

Wouldn’t it be great if we didn’t have to settle for maintained? Variants makes this possible.

Common Scenario for MAINTAINED status

Maintained status occurs because we only partially maintained authorisation proposal inside SU24. This is needed when a transaction code belongs to multiple roles with differently underlying authorisations values.

For example, if we had a transaction that provided table maintenance then we would provide authorisation object S_TABU_NAM. This object contains fields Activity and Table Name. We cannot maintain the Activity proposal in SU24 if we need to grant access to users in either display or maintenance mode. However, both roles would need the same Table Name. As a result, we would partially maintain the proposal: Activity field would remain blank, and Table Name would contain the entry.

For example, transaction OB52 provides access to posting periods. Many users may need display access and only a few need to make changes. Within transaction SU24, SAP provides the ACTVT Activity field as an empty proposal which is then maintained at role level.

Within transaction PFCG, we would receive a STANDARD proposal initially that is then set to MAINTAINED once we finish populating the Activity proposals (one role gets display only whilst the other role gets change and display).

Other Scenarios for MAINTAINED status… and where it can get messy

MAINTAINED Status can also be due to:

• SAP Proposal and Upgrades remain unchanged – the customer chooses to leave the default proposals as is and make all necessary refines at role level.
• Cockpit Style Transactions – the application has several use cases controlled through combinations of authorisations. The SU24 default proposals remain predominately empty to provide the flexibility to maintain values at role level.
• HR Authorisations and transaction – most HR transaction access is controlled through two (2) main objects – P_ORGIN and PLOG. The objects contain fields for activity level, infotype, and enterprise data restrictions. To avoid CHANGE and MANUAL status, these objects are added with empty proposals and all changes are managed at role level.

SAP Proposals and Upgrades

SAP provides default proposals for SAP standard transactions. These values are shipped via transaction SU22 tables and copied across to transaction SU24 tables via transaction SU25 (for greenfield systems, Step 1 is run).

The customer is allowed to make changes to the SAP proposals. Within transaction SU24, you can compare the values in your system against SAP proposals to check if you have deviated from the original.

As part of upgrades, SAP ships new values (changes to existing mappings and mappings for new transactions). The customer uses transaction SU25 Steps 2a/2b to compare customer tables and SAP tables to import changes.

However, for many customers, it becomes a challenge to decide if they should adopt SAP updates on transactions that they have already maintained. Depending on build maturity, it can be difficult to change which proposals are a better fit: SAP’s latest proposals or updates the customer made as part of build refinement.

Some security administration teams avoid making changes to SAP standard proposals. In this situation, it leads to an increased level of CHANGED and MANUAL authorisations – what we’re trying to avoid. However, it makes upgrades a bit easier for the security team to process.

Cockpit style transactions

The transaction is a single-entry point for several functional scenarios and assigned to multiple roles. In this situation, SU24 proposals have a higher incomplete rate and requires individual maintained in each role. Each role requires a different combination of fields values. This level of localisations shifts the build effort to the security administrator as part of role build.

HR Authorisations and transactions

HR authorisation objects control personnel record and organisational structure for infotype access. If you attempt to use transaction SU24 proposals, in most cases you are forced to enter an empty proposal in SU24 as each role requires different values. For example, transaction code PA30 for Maintain Personnel Record requires P_ORGIN authorisations to control activity level, data access, and Infotypes. Several users may need access to the transactions but different functional access. Therefore, P_ORGIN would need to be empty in SU24 and fully maintained in PFCG. It can make it difficult in HR-centric roles to determine why the roles has field values as you cannot determine the context by the role menu items. Often, security administrators resort to manually adding objects instead of attempting SU24 maintenance.

A use case of needing variants in SU24

Using the “cockpit style: scenario, let’s imagine you want to provide users with access to F3163 Manage Business Partner Master Data. This application allows you to access Suppler, Customer, and Employee information and is included in several business role templates. Many users will have a requirement to access the application, but they will need to be restricted to specific data.

Fiori App F3163 authorisation is based on SAP Gateway Service “MD_BUSINESSPARTNER_SRV             0001”. Within SU24, default proposals are provided but they are for maintenance access with no specific limit to business part role. This means without changing the proposal within transaction SU24, all restrictions will need to be at role level. Making changes are role level will result in MAINTAINED, CHANGED, or MANUAL status. Alternately, SU24 can be updated to remove the field proposals and leave empty values to maintain entirely at role level (end up with MAINTAINED only) but that doesn’t a consider different maintenance level (e.g. deletion access may be restricted).

Each time the application is added to a role, the administrator then must make changes. However, SU24 variants can solve this problem and allow you to continue with STANDARD proposals. Within, transaction SU24, a variant is created with the required mapping.

Transaction code PFCG now contains an Application Tab which will list the available Variants for each application maintain. This tab is populated after the role menu is refreshed and SU24 definitions have been read in. In the example below, the options are greyed out as there are no variants to choose between.

Once the variants have been selected, the SU24 proposals are then imported via the Authorisation Tab. Again, in this example there are not variants sot the SAP standard values will be adopted.

The security role administrator will need to work through each authorisation proposal to either set the unrequired authorisations to inactive, complete field proposal, or return to transaction SU24 to make proposal changes at the master data and then return to the role to continue build. However, as this application is used by several process areas (procurement, sales, HR, etc), it is unlikely SU24 proposals will be changed as it impacts all roles. Instead, the proposals will end up in a MAINTAIN or CHANGED status to maintain the required authorisation for the role. Ultimately, you start to lose the benefits of SU24 proposals, or you must remove all proposals in SU24 and maintain everything inside of PFCG.

Finally what are these variants and how to use them

Originally this capability was delivered under a “new” transaction code SU24N but has seen been merged back into transaction SU24. Refer to SAP Note: 2798443 – SU24N: New dialog environment for authorization default value maintenance

Transaction SU24 now allows you to create variants of the maintenance proposals. This means you can create multiple proposal versions and control which ones you adopt within the roles.

Within SU24 transaction you can how choose to CREATE VARIANT instead of changed SAP standard proposals for an application. When creating the variant you must enter this in the customer namespace. You can implement a naming convention (such as including Fiori Application Id which can help for context later).

As this is  workbench object, you will need to assign it to a transport (no screen shot shown). Once you have created the VARIANT you can start making changes to the proposal data without updating the standard values.

In the case of this application and the context of managing Supplier, you can now switch off authorisation proposals that are not relevant as well as changing the existing proposals for values that are more relevant to supplier master data.

Once you have completed the updates you then save (just like you would have when you made updates to the standard proposal)

Return to transaction PFCG and look and go to the Application Tab. You will now. The SU24 variants are automatically identified based on applications in the role menu.

As a variant now exists, you can choose which on you select for the role authorisation proposals. If there are several variants, you can choose as many as required for the role.

Once you have selected the applicable variant, save the role before you maintain authorisation data again. On the authorisation tab you will need to select Expert Mode for Profile Generation > Read Old/Merge with new to re-read the SU24 values and pick up the VARIANT proposals

You will still be asked to enter the organisational values (or update them if you need to).

The authorisation data will show more STANDARD (green) proposals due to the VARIANT that you maintained

When reviewing the authorisation proposal you will now see which specific variant brought them in.

As mentioned, when creating a VARIANT in SU24, the variant name is quite useful to understand the context. As shown above, the application variant name of “ZF3163_SUP_M” is a basic naming convention for the Fiori App F3163 with variant of Supplier Maintenance. These conventions can make it easier to understand the access context compared to the application Odata service name.

Impacts of Using Variants

The primary benefit of using variants is to allow you to leverage authorisation default proposals from SU24 and minimise overall maintenance of individual permission within the role. The following are benefits I can see in using variant in SU24

• Able to easily handle different access contexts for the same application.
• Separate development/maintenance default mappings with security roles team
• Reduce access creep and confusion in role build through less direct maintenance of value
• Obtain better access context through variant names to better understand reason authorisation proposal within a role
• Easily able to add a new variant to an application for another role without having to maintained the existing roles. This can occur when you add an application in design but need to change the SU24. If you update the SU24 data, then you would need to also maintained the existing role and regression test. This further add to your change request and effort. Instead, you can define a new variant just for those values.
• Reduce SU25 Step 2a/2b upgrade effort as you avoid maintaining SAP standard proposals. However, you will need to manually assess your variants to decide if you need to add new value proposals that were added to the SAP original
• Flexibility to differentiate access proposals for non-production and production access. This can allow security teams to leverage SU24 for project role build for sensitive transactions that would generally be granted in display mode only.
• Small win – your can double-click on the variant tab line items of transaction PFCG to navigate to the related transaction SU24 configuration to confirm you have selected the required variant.

Give variants a go and share your thoughts below. I’d love to know if this is something you’d consider using as part of  your build accelerator and approach to consistently building security roles.

Cheers

Colleen

P.S. For those of you who are new to building security roles ABAP authorisations roles via transaction PFCG, the authorisations status is summarised in the table below: