Provisioning vs. Federated Role Assignment auf SAP BTP

Die Grundsatzfrage bei jeder BTP-Einführung

Wer die SAP Business Technology Platform einführt, steht früher oder später vor einer Architekturentscheidung, die selten die Aufmerksamkeit bekommt, die sie verdient: Wie kommen Benutzer zu ihren Role Collections? Die Antwort hängt davon ab, ob man von der Identität des Benutzers spricht oder von der Berechtigung, die er erhält — zwei Ebenen, die in der Praxis häufig vermischt werden, obwohl für sie unterschiedliche Antworten gelten.

Die offizielle SAP-Dokumentation zur Autorisierung auf BTP-Ebene nennt drei Methoden: Manual Assignment, Federation und Provisioning — mit einer klaren Präferenz: Provisioning wird gegenüber Federation empfohlen, wo immer es möglich ist. Genau diese Empfehlung führt in der Projektpraxis regelmäßig zu einem Missverständnis, das dieser Artikel auflösen soll.

Zwei Ebenen, die man nicht vermischen sollte

Bevor man fragt „ist das jetzt Federation oder Provisioning?", lohnt sich eine Vorfrage: Auf welcher Ebene befinden wir uns gerade?

Ebene 1 — Identität: Existiert der Benutzer, und in welchen Gruppen ist er Mitglied? Diese Frage wird ausschließlich in den Cloud Identity Services beantwortet — und hier ist die Antwort klar und ohne Ausnahme: Identitäten werden immer provisioniert, kein Shadow-User-Konzept.

Ebene 2 — Berechtigung: Welche Role Collection erhält dieser Benutzer in der BTP bzw. der Anwendung? Diese Frage beantwortet die Subaccount-Trust-Configuration — und hier gibt es tatsächlich zwei mögliche Antworten, deren Verhältnis zueinander den Rest dieses Artikels ausmacht.

Die Unschärfe entsteht, wenn beide Ebenen so behandelt werden, als gäbe es nur eine gemeinsame Antwort. Das ist nicht der Fall.

Federation: Rollen aus dem Token

Federation ist laut SAP eine Vereinbarung zwischen dem Identity Provider und dem konsumierenden System, welche Attribute in Authentifizierungs-Tokens transportiert werden. Meldet sich ein Benutzer an einer BTP-Anwendung an, transportiert das SAML-Assertion beziehungsweise das OIDC-Token seine Gruppenzugehörigkeiten als Claims. Die BTP weist Berechtigungen indirekt auf Basis dieser Attribute zu — technisch: Role Collection Mapping. In der Plattform selbst wird nichts dauerhaft gespeichert — die Zuweisung entsteht zur Laufzeit, bei jedem Login neu.

Der Vorteil: Berechtigungsänderungen wirken sofort — sobald die Änderung beim Identity Provider vorgenommen wurde, gilt sie beim nächsten Login, ohne auf einen Provisioning-Lauf zu warten. Der Nachteil: Welche Berechtigungen ein Benutzer hat oder welche zusammengehören, lässt sich nur manuell über Mapping-Regeln (z.B. in Excel) abbilden. Und wird ein Benutzer beim Identity Provider entfernt, bleibt sein Benutzer im Zielsystem bestehen — die Löschung muss aktiv nachgezogen werden.

Hinweis: Die Token-Grenze ist Entra-ID-spezifisch, kein SAML/OIDC-Standardverhalten

Federation stößt in gewachsenen Organisationen an eine harte technische Grenze — allerdings nicht, weil SAML- oder OIDC-Tokens grundsätzlich in ihrer Kapazität begrenzt wären, sondern weil Microsoft Entra ID als Token-Aussteller ein eigenes Verhalten zeigt: Oberhalb von rund 150 Gruppen bei SAML beziehungsweise rund 200 Gruppen bei OIDC/JWT ersetzt Entra ID den vollständigen Gruppen-Claim durch einen Verweis auf die Graph API. Löst das empfangende System diesen Verweis nicht auf, wirken fehlende Berechtigungen scheinbar willkürlich — und in gewachsenen Organisationen mit feingranularen Rollenmodellen wird diese Schwelle schneller erreicht, als viele erwarten. Hinzu kommt ein Governance-Problem: Wer wann welche Rolle effektiv hatte, lässt sich aus einem flüchtig ausgewerteten Token nur schwer rekonstruieren — für Audits und Rezertifizierungen eine schwache Basis.

Provisioning: Benutzer und Rollen werden direkt ins Zielsystem geschrieben

Der Identity Provisioning Service (IPS) wird in der Praxis für zwei unterschiedliche Aufgaben eingesetzt, die beide „Provisioning" heißen, aber verschiedene Ebenen betreffen:

Identity Provisioning (Ebene 1): IPS synchronisiert Benutzer und Gruppenzugehörigkeiten aus dem Quellsystem (z. B. Entra ID) in die Identity Directory der Cloud Identity Services. Das ist reine Identitätssynchronisierung — kein Autorisierungsmechanismus. Diese Form von Provisioning ist die Grundlage jeder Landschaft, ohne Ausnahme.

Provisioning als Autorisierungsmethode (Ebene 2, per SAP-Definition): Der IPS schreibt zusätzlich die eigentliche Role Collection direkt in ein Zielsystem, orchestriert über zentral definierte Business Roles, ohne dass beim Login eine Mapping-Regel ausgewertet wird. Vorteil: automatisiertes, regelkonformes Deprovisioning beim Austritt. Nachteil: eine gewisse Latenz, bis eine neue Berechtigung wirksam wird. Die entscheidende Einschränkung: SAP nennt diese Form nur „partially available" für Plattform-Nutzer. Direkt provisionierbar sind vor allem Role Collections auf Subaccount-Ebene, etwa „Subaccount Administrator" oder „Business_Application_Studio_Developer". Bei anderen SAP Cloud Applikationen außerhalb des Subaccounts sieht das oft anders aus. Oft müssen dafür zuerst die Rollen ausgelesen werden. Hier warten wir aus der administrativen Perspektive leider noch auf die "fully harmonized Suite".

Die Konsequenz: Identität ist provisioniert, Berechtigung ist oft trotzdem Federation

Genau hier liegt die Verwechslung, die in vielen Projektgesprächen für Verwirrung sorgt: Weil die Identität (Ebene 1) korrekt und ausnahmslos provisioniert wird, wird oft angenommen, die daraus abgeleitete Berechtigung (Ebene 2) sei es automatisch auch. Für die meisten Fälle stimmt das nicht. Sobald die BTP eine Role Collection Mapping aus einem CIS-Gruppenattribut ableitet, ist das nach SAPs eigener Definition Federation — unabhängig davon, dass die zugrunde liegende Gruppenzugehörigkeit sauber provisioniert wurde.

Unsere Empfehlung

Aus dieser Trennung folgt eine klare, zweigeteilte Architekturentscheidung.

Auf Ebene der Identität: Immer Provisioning

Jeder Benutzer und jede berechtigungsrelevante Gruppenzugehörigkeit wird vorab per Identity Provisioning in das Zielsystem geschrieben — bevor sich der Benutzer das erste Mal anmeldet. Kein Shadow-User-Konzept: Ein bei der ersten SSO-Anmeldung automatisch angelegter Benutzer hat keine saubere Lifecycle-Anbindung an die Quelle. Verlässt der Benutzer die Organisation, bleibt sein Datensatz im Zielsystem bestehen, bis ihn jemand aktiv findet und löscht — exakt der Federation-Nachteil, den SAP selbst benennt. Wird die Identität stattdessen vorab durch IPS provisioniert, greift beim Austritt automatisiertes Deprovisioning. Diese Entscheidung gilt ausnahmslos — unabhängig davon, wie die Berechtigung später zugewiesen wird.

Ergänzend gilt: Die BTP-Subaccounts vertrauen ausschließlich den Cloud Identity Services als Identity Provider — nicht direkt Entra ID. Jedes Attribut, das im Trust-Config-Mapping ausgewertet wird, stammt aus der bereits provisionierten CIS Identity Directory, nie aus einem live durchgereichten Entra-ID-Claim. Die Cloud Identity Services werden damit zur einzigen Quelle der Wahrheit für Identitäten — und das oben beschriebene Entra-ID-spezifische Overage-Verhalten betrifft nur noch die IPS-Synchronisierung im Hintergrund, die per Paging ohnehin nicht davon eingeschränkt ist, nicht mehr das Login-Token an die BTP.

Auf Ebene der Berechtigung: ein hybrides Modell

Anders als bei der Identität gibt es hier keine einheitliche Antwort — und das ist auch richtig so. Für die Masse der Business-Anwender-Berechtigungen bleibt Federation über Role Collection Mapping der passende Mechanismus: schnell wirksam, aber immer auf Basis der bereits provisionierten CIS-Gruppenzugehörigkeit, nie eines live durchgereichten Attributs. Für ausgewählte Plattform-Role-Collections — insbesondere administrative Rollen auf Subaccount-Ebene — lässt sich Provisioning im engen SAP-Sinn direkt einsetzen, mit den entsprechenden Governance- und Deprovisioning-Vorteilen.

Am Ende einer sauber durchdachten BTP-Berechtigungsarchitektur steht damit kein einheitlicher Mechanismus, sondern ein bewusst hybrides Modell: konsequentes Provisioning auf Identitätsebene, eine Mischung aus Federation und Provisioning auf Berechtigungsebene — je nachdem, welche Rolle betroffen ist.

Fazit

Die Frage lautet nicht „Federation oder Provisioning?", sondern zunächst: Sprechen wir gerade über Identität oder über Berechtigung? Auf Ebene der Identität gibt es dafür nur eine Antwort: immer provisionieren, nie als Shadow User entstehen lassen. Auf Ebene der Berechtigung ist die Antwort bewusst hybrid — Federation für die Mehrheit der Business-Rollen, Provisioning für ausgewählte Plattformrollen. Wer diese Unterscheidung von Anfang an sauber trifft, baut eine BTP-Berechtigungsarchitektur, die mit der Landschaft wächst, Audits standhält und im Tagesgeschäft wenig Pflege braucht.

Sie stehen vor genau dieser Architekturentscheidung oder möchten Ihr bestehendes Rollenmodell auf ein tragfähiges Fundament stellen? Wir unterstützen Sie mit einer erprobten Vorgehensweise — von der Analyse über das Zielbild bis zur Umsetzung. Erfahren Sie mehr über unsere Beratung zu Identity & Access Management für SAP-Landschaften.

Für die Plattform-Themen dahinter — Architektur, Subaccounts, Security — steht Ihnen unsere SAP BTP Beratung zur Seite.