SAP Roles

An SAP role is a container of authorizations (and often a menu) representing what a particular job function should be able to do, for example an "AP Clerk" role granting the transactions and authorization objects needed to process vendor invoices. Users get access by being assigned roles, never by direct authorizations.

• Single role: a set of authorizations plus a menu, generated into a profile.
• Composite role: a bundle of single roles, convenient for assigning a whole job’s worth of access at once.

This is the mechanism underneath everything else, and it is worth understanding once properly.

An authorisation object is a template with up to ten fields. S_TCODE has one field, the transaction code. M_BEST_BSA, for purchase order document types, has an activity field and a document type field.

An authorisation is that object filled in with values: activity 01 for create, document type NB. A role holds many of these, and a user's roles combine into their authorisation profile.

When code runs an AUTHORITY-CHECK, it names an object and the values it needs. The system looks through the user's authorisations for that object and passes if any one covers all the requested values. That last point is the source of most confusion: the values must all be satisfied by a single authorisation, not assembled from two.

Two users with the same transactions and different field values therefore have genuinely different access. Someone with activity 03 on purchase orders can display them and not create them, using the same transaction code.

SU53 shows the last failed check for a user, which is the fastest way to see exactly which object and value was missing. ST01 or the newer trace does the same in more detail when the failure is intermittent.

In PFCG you add transactions/apps to the role menu, then maintain the authorization objects (with their field values) that those transactions check, and generate the authorization profile. Getting the authorization-object values right is the craft of SAP security.

Half an hour, and it teaches more about authorisations than reading about them for a day.

1. Create a single role in PFCG and add one transaction to its menu, such as ME23N.
2. Open the authorisations tab. Objects have been proposed from the transaction, and several fields are marked as needing values.
3. Fill only the activity field with 03, display. Generate the profile and assign the role to a test user.
4. Impersonate the user and run the transaction. It opens. Now try ME21N to create an order: refused, because the transaction is not in the role.
5. Add ME21N to the menu but leave activity at 03. It now fails on the document authorisation rather than the transaction, and SU53 shows exactly which object and which value.

Step five is the distinction that matters: reaching a transaction and being allowed to do something in it are two separate checks, and knowing which one failed halves the diagnosis. See SAP administration security for the wider picture.

Well-designed roles grant exactly what a job needs, no more. Over-broad roles create audit findings and risk; a clean role design is foundational to SAP security and SoD control.

The tension worth naming: least privilege conflicts with getting work done, and every organisation resolves it somewhere on that line. Too tight and people cannot do their jobs, so emergency access is granted and never revoked. Too loose and segregation of duties fails an audit. The practical answer is a role design that follows real jobs rather than the org chart, reviewed periodically, with a controlled route to elevated access rather than a permanent one. See Fiori roles for how this reaches the launchpad.

One structural point that saves a lot of rework: decide early whether organisational values are carried in derived roles or in the role itself. A design that hardcodes plant or company code into every role produces a new role for every combination, and by the time that is obvious there are hundreds of them.

Roles are only half of it. Somebody has to be assigned one, and the joiner, mover and leaver sequence is where access control succeeds or fails.

Joiner. A new user needs the roles for their job, and the temptation is to copy a colleague. That propagates whatever excess the colleague accumulated, invisibly. A role catalogue that maps job to roles is the alternative, and it is what makes provisioning repeatable.

Mover. The failure mode of the three. Somebody changes department, gains the new roles, and keeps the old ones. Over a career that accumulates into a user who can do far more than their job, and it is exactly the profile that fails a segregation of duties check.

Leaver. Access must be removed promptly. A locked account still holds its roles, which is fine, and a forgotten one that is never locked is a live credential.

SU01 maintains a user, SU10 does it in bulk, and SUIM is the information system that answers who has what. SUIM is the tool for an access review, and running it periodically is the control that catches the movers.

Reference users and derived roles help at scale: a derived role shares its parent's transactions and varies the organisational values, so one design serves twenty plants without twenty maintenance jobs.

• Job-based or task-based roles. One composite per job is easy to assign and duplicates authorisations across jobs. Small task roles combine flexibly and multiply the number of objects to manage. Most designs land on task roles grouped into job composites.
• Derived roles or separate ones. Where the same job exists at twenty plants, a parent role with derived children varying only the organisational values is one design to maintain instead of twenty.
• Who approves an assignment. The line manager knows the job; the role owner knows what the role permits. Both are usually needed, and an approval by neither is a rubber stamp.
• How often access is reviewed. Annually is common and it is slow enough that a mover's excess persists for months. Quarterly for privileged access is a reasonable compromise.

• Over-broad roles violating least privilege.
• Assigning authorizations directly instead of via roles.
• Not regenerating profiles after changing a role.

• Copying a working user's roles for a new starter. It propagates whatever excess that user accumulated, and it does so invisibly.
• Changing a role without regenerating the profile. The change exists and does not take effect.
• Using SAP_ALL to unblock somebody. It works, and it is the reason audits find production users with unlimited access. See SAP job roles for the people side.

• Roles designed around the org chart. Departments reorganise and job functions do not, so roles built on functions survive far longer.
• No role owner. A role nobody owns accumulates transactions on request and is never trimmed.

Building a role is straightforward, and designing a role concept that satisfies both the business and an auditor is the part you do in the course.

The diagnostic habit worth building is running SU53 as the affected user immediately after the failure. It names the object and the value that was missing, which turns an authorisation problem from guesswork into a lookup.