Explain SAP User Administration & Authorization Concept in SAP

15 / 65

Basisintermediate

SAP User Administration & Authorization Concept

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

Authorization design shows up constantly in Basis and security-consultant interviews because getting it wrong has two equally bad failure modes - too permissive (segregation-of-duties violations, audit findings) or too restrictive (users can't do their jobs, endless helpdesk tickets) - and a good candidate can articulate the trade-off explicitly rather than treating roles as a black box someone else configures.

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

The core building block is the authorization object - a template with up to ten fields (e.g., activity, company code, plant) that a program checks at runtime via AUTHORITY-CHECK. A role (PFCG) bundles authorization objects with specific field values into a coherent job function (e.g., "AP Clerk"), generating an authorization profile that's actually assigned to users. Composite roles bundle several single roles together for a broader job function spanning multiple areas, while derived roles inherit the menu and authorization structure of a parent role but allow organizational-level values (like company code or plant) to differ per derived child - a common pattern for the same job function repeated across multiple plants or regions.

AUTHORITY-CHECKPFCG

The authorization check itself is explicit in ABAP code (AUTHORITY-CHECK OBJECT ... ID ... FIELD ...), meaning a program simply won't be secure if the developer forgot to add the check - this is a very common real-world vulnerability and a good interview probe of whether a candidate understands security is not automatic. The SU53 transaction shows the last failed authorization check for a user's most recent action, and ST01/the newer authorization trace is used for more thorough analysis when SU53 isn't enough (e.g., checks that failed several steps earlier).

AUTHORITY-CHECK OBJECT ... ID ... FIELD ...SU53ST01

A senior-level answer also brings up segregation of duties (SoD) - ensuring no single role combination lets one person both create and approve a payment, for example - typically governed by a GRC (Governance, Risk, and Compliance) tool that scans role assignments for conflicting authorization combinations, and mentions user types (dialog, system, communication, service) as a security hardening consideration since only dialog users should generally be allowed interactive logon.