SAP Authorizations

When a user attempts an action, SAP performs authorization checks against authorization objects, each with fields (for example, activity, company code, plant) that must match values the user holds. The user’s values come from the authorization profiles generated from their roles. If the check fails, access is denied.

Where the check happens is worth knowing too. It is the program that calls AUTHORITY-CHECK, at whatever point the developer put it, which means a transaction can let you in and refuse an action three screens later. It also means custom code without a check has no authorisation at all, however carefully the roles were designed, and that is one of the standard findings in a code review.

An authorization object groups related fields, for example, an object might check activity (create/change/display) and organizational level (which company code). A role grants specific field values, so you can allow "display for company code 1000" but not "create for company code 2000".

The activity field deserves knowing by value, because it appears on most objects and the numbers are consistent. 01 is create, 02 change, 03 display, 06 delete, and there are others per object. A role granting 03 and nothing else is a genuine read-only role, and one granting an asterisk on activity grants every operation the object supports, including ones nobody thought about.

One property of the check decides more outcomes than anything else, and it is rarely stated plainly.

When a program checks an object with several field values, the user passes only if a single authorisation covers all of them. Values cannot be assembled from two authorisations.

An example makes it concrete. A user holds one authorisation for purchase orders with activity 03 in company code 1000, and another with activity 01 in company code 2000. Asked to create a purchase order in company code 1000, they are refused, even though they hold activity 01 somewhere and company code 1000 somewhere. Neither authorisation covers both.

This is why SU53 output can look wrong. The user plainly has the activity and plainly has the company code, and they still fail, because those values live in different authorisations.

It is also why role design matters more than role count. A role built around a real job holds the combinations that job needs together. Roles assembled from fragments produce users who appear to have everything and can do nothing.

When a user hits an authorization error, transaction SU53 shows the failed check (which object and values were missing), and ST01/STAUTHTRACE traces checks in detail. This is the everyday tool for figuring out what a role is missing.

STAUTHTRACE deserves more use than it gets. Where SU53 shows only the last failure, the trace records every check a user's session performed, passed and failed, which is what you need when building a role for an unfamiliar transaction: run the process with the trace on, and the result is the list of objects and values that role must contain.

An hour, and it is how roles are actually built for anything non-standard.

1. Start STAUTHTRACE filtered to a test user.
2. Have that user, holding minimal access, run the business process end to end. It will fail repeatedly, which is the point.
3. Stop the trace and read the list. Every object checked, with the values requested.
4. Build a role containing those objects with those values, restricted to the organisational scope the job actually needs rather than what the trace happened to touch.
5. Assign it to a fresh test user with nothing else, and run the process again.
6. Repeat until it completes. What you have is a role derived from what the process needs rather than from guesswork.

Step four contains the judgement: the trace tells you which objects, and a human decides how wide the values should be.

Fine-grained authorizations enable least privilege and separation of duties, ensuring, for example, that no one can both create and pay a vendor. Getting authorization design right is what makes SAP auditable.

The mechanism that makes least privilege maintainable at scale is organisational levels. Certain fields, company code, plant, purchasing organisation, are marked as organisational, and a derived role inherits everything from its parent except those. One parent design serves every site, and a new site is a derived role rather than a new build. Without that, a landscape of twenty plants produces twenty independently maintained roles that drift apart.

There are hundreds of authorisation objects and a handful carry most of the risk. Knowing them makes a review tractable.

S_TCODE is the gate on every transaction, and it is the first check made.

S_DEVELOP grants development and debugging. In production it allows changing data in the debugger, which bypasses every other control in the system, and it should be absent there.

S_USER_GRP, S_USER_AGR and the related objects control user and role administration. Somebody with these can grant themselves anything, so they are the definition of privileged access.

S_TABU_DIS and S_TABU_NAM control direct table maintenance. Wide access here means editing table contents without an application, which is the other route around business logic.

S_RFC governs which function modules a remote call may execute, and it is frequently left wide because restricting it breaks interfaces that nobody documented.

S_BTCH_JOB and its relatives cover background job scheduling, including running jobs as another user.

An access review that starts with these six answers most of what an auditor will ask, and it is a morning's work rather than a project.

• How roles map to jobs. One composite per job assembled from task roles is the pattern that scales. One role per person does not.
• Which fields are organisational levels. This determines what derived roles can vary and it is set once, so getting it wrong means rebuilding rather than adjusting.
• Whether display access is broad. Wide read access is convenient and it is still access to data, and in HR and finance it is exactly what a data protection review asks about.
• How new transactions reach roles. A defined route, or requests handled one at a time, which is how roles quietly widen.

• Granting wide-open values (*) instead of specific ones.
• Not using SU53/traces to diagnose errors.
• Ignoring SoD conflicts in authorization design.

• Adding a value to a shared role to unblock one person. Everyone holding that role now has it.
• Building roles from a trace without trimming. The trace shows what was touched, including things that happened to be checked, and copying it wholesale produces roles wider than the job.
• Forgetting to regenerate the profile. See client administration, background jobs, background processing and licences for the neighbouring administration areas.

• Asterisk values left from a trace-built role. They pass every check, which is why they get left in, and they are the definition of the excess an audit finds.
• Testing a role while holding another. The other one is what made it work.

Reading a failed check is the diagnostic half, and designing an organisational level structure that scales across sites is the part you do in the course.

The single rule to carry from this page: one authorisation must cover all requested values. It explains the refusals that look impossible, and it is why role design around real jobs beats assembling fragments.