All topics
15 / 65
Basisintermediate

SAP User Administration & Authorization Concept

Roles, authorization objects, profiles, and how SAP's authorization check mechanism controls what users can do.

SAP decides what a user may do by checking authorization objects in code. Everything else — roles, profiles, composites — is machinery for assigning values to those checks.

An authorization object is a lock with several tumblers (fields); a role is a specific key cut to open exactly the locks (transactions/data) needed for one job function, and a derived role is the same key blank re-cut slightly differently for a different branch office.

Key Concepts

1
The check is written by a developer, explicitly.
    AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'
             ID 'BUKRS' FIELD lv_bukrs
             ID 'ACTVT' FIELD '01'.
    IF sy-subrc <> 0.
      MESSAGE 'Not authorised' TYPE 'E'.
    ENDIF.
2
This is the point most people miss. Nothing is automatic. A custom report that reads the same table without this statement has no security at all, whatever roles exist.
3
Worse, a check whose sy-subrc is not tested is decoration — the check runs, fails, and the program continues. Both are common findings in real systems.
sy-subrc
4
An authorization object is a template. Up to ten fields, such as company code and activity. A role fills in the values.
5
Roles, in PFCG. A role bundles objects with values into a job function — "AP Clerk" — and generates a profile, which is what is actually assigned to the user.
PFCG
6
    single role     one job function, with values
    composite role  several single roles, for a broader job
    derived role    inherits a parent's menu and objects, but its own
                    organisational values
7
Derived roles are worth understanding properly, because they solve a real problem. The same job in forty plants would otherwise be forty hand-maintained roles. Instead one parent holds the structure, and forty children differ only in the plant value.
8
Change the parent and the change flows to all forty. The organisational values stay per child. That is the difference between maintaining one role and forty.
9
Diagnosing a failure. SU53 shows the last failed check for a user — run it immediately after the error, and it names the object and the value that was missing.
SU53
10
Its limitation is that it shows the last failure. When a program checks several things and the relevant failure was several steps earlier, SU53 shows the wrong one. Then use the authorization trace (STAUTHTRACE, or ST01 on older systems), which records every check performed.
SU53STAUTHTRACEST01
11
Two things a senior answer adds.Segregation of duties. No single person should be able both to create a vendor and to pay one, or to enter a payment and approve it. That is a rule about combinations of roles, not about any one role, so it is checked by a GRC tool scanning assignments for conflicting pairs.
12
User types. Only dialog users should be able to log on interactively. A system or communication user runs interfaces and background work, and setting an interface user as dialog gives anyone who obtains that password a working logon — usually with broad authorisations, since interface users tend to have them.
13
The failure modes are symmetrical. Too permissive is an audit finding and a fraud risk. Too restrictive is a help desk queue and users sharing logons to get work done — which is worse than the problem it solved.
14
What the interviewer is probing.1. "How do authorization objects, roles and profiles relate?" Probing: the model. Stalls: "Roles give access." Moves up: objects define checkable fields, roles contain authorizations for them, and generating a role produces the profile actually assigned to the user.
15
2. "What is a derived role for?" Probing: the design pattern. Stalls: "Copying." Moves up: a parent role holding the functions with children differing only in organisational values, so a function change is made once.
16
3. "How do you find the authorization a user is missing?" Probing: the practical skill. Stalls: "Guess." Moves up: SU53 right after the failure, or an authorization trace in STAUTHTRACE for a repeatable capture.
17
4. "Why is SAP_ALL dangerous even in development?" Probing: the discipline. Stalls: "It is fine there." Moves up: it hides missing authorizations so problems surface only in production, and it is an audit finding on its own.
Use cases:authorizationpfcgsecuritysod