SAP PFCG

It maintains authorization roles, the menu and authorization objects, and generates the profiles assigned to users, the heart of SAP authorization design.

• Role name (single/composite).
• Menu tab (transactions/apps in the role).
• Authorizations tab (objects and field values).
• Generate profile; user assignment tab.

Three kinds of role exist and choosing the wrong one is a design decision people live with for years.

A single role holds a menu and authorisations and generates a profile. This is where the actual authorisation values live.

A composite role holds only a list of single roles. It generates nothing itself and is a convenience for assigning a bundle to a user. Useful for job based assignment, and it adds a layer, so a landscape with composites of composites is one nobody can answer questions about.

A derived role inherits its menu and authorisations from a parent and keeps its own organisational values. This is the mechanism for the same job in different company codes or plants: one parent maintained once, many children differing only in the organisational fields. Getting this right is the difference between maintaining one role and maintaining forty.

The decision rule: derive when the difference between roles is purely organisational, and build separate singles when the difference is functional.

• Add transactions to the menu, then maintain the pulled-in authorization objects.
• Regenerate the profile after any authorization change.
• Use SU24 defaults to reduce manual authorization work.

The habit that prevents most authorisation incidents: build from the menu, never by adding objects by hand. Adding a transaction pulls in the objects SU24 says it needs, in the right shape. Adding objects manually produces a role that works for the case you tested and is missing something for the case you did not, and it is invisible until a user hits it.

Roles are ordinary data and knowing the tables makes reporting on them possible.

• AGR_DEFINE the roles themselves.
• AGR_1251 the authorisation objects and field values, which is the table almost every authorisation report reads.
• AGR_USERS the user assignments, with validity dates.
• AGR_TCODES the transactions in each role's menu.
• AGR_AGRS the composite to single relationships.

The neighbouring transactions do the jobs PFCG does not. SU24 holds the default authorisation objects proposed when a transaction is added to a menu, and maintaining it properly is what stops every role build being manual work. SU53 shows the last failed authorisation check for a user, which answers "why can they not do this" in seconds. SUIM reports across roles and users. PFUD performs the user master comparison, which is what actually pushes profile changes into user master records.

• Forgetting to regenerate the profile (changes not effective).
• Over-broad authorizations (*) instead of least privilege.
• Missing objects causing SU53 authorization failures.

Two more worth knowing because they look like PFCG problems and are not. A change to a role does not reach users until the profile is generated and the user master comparison has run, so a correct role can still fail for a user until PFUD catches up. And SAP_ALL on any account in a production system is a finding in every audit, whatever the justification offered.

Around it: SU01 maintains the users the roles are assigned to, ST22 shows dumps that are sometimes authorisation failures in disguise, and SM59 holds the RFC destinations whose service users need their own carefully scoped roles.

Version note: the transaction is unchanged on S/4HANA and the tables above are the same. What changed is scope: with Fiori, a user needs both the back end authorisations described here and the front end catalog and group assignments that put tiles on their launchpad. A correct PFCG role with no catalog assignment gives a user the right to do something they cannot see.

• Editing authorisation values by hand instead of through the menu. The next regeneration or SU24 sync overwrites what you typed, and the role reverts without anybody noticing.
• Changing a parent role and not pushing to its derived children. The parent is correct, the children are stale, and only the users on one plant are affected.
• Assuming generation reaches users. Generating the profile is not the same as the user master comparison. Until PFUD has run, a correct role can still fail for the person assigned it.
• Fixing an SU53 by adding exactly the object it named. That resolves one failed check and the user hits the next one tomorrow. Trace the whole transaction rather than the last failure.
• Granting a wildcard to unblock somebody. It works immediately, it is never revisited, and it is what an audit finds.