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 Rollen? Zwei grundsätzlich verschiedene Wege stehen zur Verfügung. Entweder werden Berechtigungen persistent in die Plattform provisioniert — gesteuert über ein zentrales Identity Management. Oder sie werden bei jeder Anmeldung dynamisch mitgeliefert, als Gruppen-Claims im Authentifizierungs-Token des Identity Providers, etwa Microsoft Entra ID.

Beide Ansätze funktionieren. Beide haben ihre Berechtigung. Aber sie haben fundamental unterschiedliche Trade-offs bei Kontrolle, Auditierbarkeit und Skalierung. Wer die Entscheidung dem Zufall überlässt, merkt das oft erst, wenn die BTP-Landschaft gewachsen ist — und ein Umbau teuer wird. Dieser Artikel zeigt, wann welcher Ansatz trägt und warum in der Praxis meist eine Kombination die beste Antwort ist.

Federated Role Assignment: Rollen aus dem Token

Bei der föderierten Rollenzuweisung pflegen Sie Gruppenmitgliedschaften ausschließlich im Corporate IdP. Meldet sich ein Benutzer an einer BTP-Anwendung an, transportiert das SAML-Assertion beziehungsweise das OIDC-Token seine Gruppenzugehörigkeiten als Claims. Auf BTP-Seite werden diese Gruppen über Role-Collection-Mappings in Berechtigungen übersetzt. In der Plattform selbst wird nichts dauerhaft gespeichert — die Zuweisung entsteht zur Laufzeit, bei jedem Login neu.

Der Charme liegt auf der Hand: kaum Systempflege, kein zusätzlicher Provisionierungsprozess, schnelles Onboarding neuer Anwendungen und Benutzergruppen. Für Pilotprojekte, kleine Subaccounts oder externe Nutzer ist das ein echter Effizienzgewinn.

Die Grenzen sind allerdings hart — und technischer Natur. Authentifizierungs-Tokens haben eine begrenzte Kapazität: Bei SAML liegt das praktische Limit bei rund 150 Gruppen pro Token, bei OIDC/JWT bei etwa 200 Gruppen. Ist ein Benutzer Mitglied in mehr Gruppen, werden Claims abgeschnitten oder durch Verweise ersetzt — mit der Folge, dass Berechtigungen scheinbar willkürlich fehlen. In gewachsenen Organisationen mit feingranularen Rollenmodellen ist diese Schwelle schneller erreicht, als viele erwarten. Hinzu kommt ein Governance-Problem: Wer wann welche Rolle effektiv hatte, lässt sich aus flüchtigen Token-Inhalten nur schwer rekonstruieren. Für Audits und Rezertifizierungen ist das eine schwache Basis.

Federation und Provisioning im direkten Vergleich

Best Practice: Claims gezielt steuern statt alles föderieren

Wenn Sie föderieren, dann kontrolliert. Der wirksamste Hebel dafür ist ein sauberes Enterprise-App-Design in Entra ID: eine dedizierte Enterprise App pro SAP-Anwendung — je BTP-Subaccount, je SAC-Tenant, je Work-Zone-Instanz. Statt pauschal alle Gruppen eines Benutzers in jedes Token zu schreiben, geben Sie pro App nur die Gruppen frei, die dort tatsächlich benötigt werden. Das hält Tokens klein, reduziert die Angriffsfläche und schafft pro Anwendung einen eigenen Audit-Trail.

Der zweite Gewinn: app-spezifische Conditional-Access-Policies. Ein Beispiel aus der SAP Analytics Cloud macht das greifbar — externe Marketing-Partner greifen auf ausgewählte Dashboards zu, während interne Controller mit vertraulichen Finanzdaten arbeiten. Mit einer dedizierten Enterprise App je Zugriffsszenario erzwingen Sie für die Controller MFA und Gerätekonformität, während die Partner eine restriktive, zeitlich begrenzte Gastrichtlinie erhalten. Ein pauschales Federation-Setup kann diese Differenzierung nicht leisten.

Provisioning: das Fundament für Governance

Beim Provisioning werden Rollenzuweisungen als persistente Objekte in die BTP geschrieben — orchestriert über eine bewährte Kette: Das führende Identity Management übergibt an den SAP Identity Provisioning Service (IPS), dieser provisioniert in den Identity Authentication Service (IAS) beziehungsweise dessen Identity Directory und von dort per SCIM in die Zielanwendungen — kurz: IDM → IPS → IAS.

Damit gewinnen Sie, was Federation strukturell nicht bieten kann: einen vollständigen Identity Lifecycle. On- und Offboarding laufen automatisiert, Abteilungswechsel ziehen Rollenänderungen nach sich, verwaiste Berechtigungen werden systematisch abgebaut. Governance-Werkzeuge wie SAP Identity Access Governance (IAG) oder die Xiting Security Platform (XSP) setzen darauf auf: Genehmigungsworkflows, Funktionstrennungsprüfungen und Rezertifizierungen greifen auf einen konsistenten, auditierbaren Datenbestand zu. Wer wann welche Rolle erhalten hat — und wer sie genehmigt hat — ist jederzeit nachweisbar. In regulierten Branchen ist das keine Kür, sondern Prüfungsanforderung. Und weil die Rollen in der Plattform liegen statt im Token, spielt die Token-Größe schlicht keine Rolle mehr.

Der Preis dafür ist ein höherer initialer Aufwand: Provisionierungsjobs, Attribut-Mappings und Transformationslogik wollen konzipiert und betrieben werden. Dieser Aufwand amortisiert sich — aber erst ab einer gewissen Landschaftsgröße.

Das hybride Modell: die pragmatische Mitte

In der Projektpraxis hat sich deshalb ein hybrides Modell bewährt, das die Stärken beider Ansätze kombiniert:

• Geschäftsnutzer werden provisioniert. Ihre Berechtigungen ändern sich mit Eintritt, Wechsel und Austritt — genau hier zahlen sich Lifecycle-Automatisierung und Governance-Workflows über die Kette IDM → IPS → IAS aus.
• Plattformrollen werden föderiert. Subaccount-Administratoren und Entwickler haben meist statische, überschaubare Rechteprofile. Wenige, stabile Entra-Gruppen genügen — das Token-Limit wird nie zum Thema, und das Onboarding bleibt schlank.

Wichtig ist dabei die konsequente Trennung auf Identity-Ebene: Produktions-, Test- und Sandbox-Umgebungen erhalten eigene Gruppen und eigene Mappings, damit ein Testzugriff nie versehentlich zur Produktionsberechtigung wird.

Entscheidungshilfe und Fazit

Als Faustregel für Ihre Landschaft:

1. Regulierte Branche, Audit-Pflichten oder mehr als eine Handvoll Subaccounts? Dann führt an Provisioning als Fundament kein Weg vorbei.
2. Feingranulares Rollenmodell mit vielen Gruppen pro Benutzer? Die Token-Limits von ~150 (SAML) bzw. ~200 Gruppen (OIDC) sprechen klar gegen reine Federation.
3. Piloten, Plattform-Admins, Externe? Hier ist Federation der schnellere und schlankere Weg — mit dedizierten Enterprise Apps und kontrollierten Claims.

Die Frage lautet also nicht „Provisioning oder Federation?", sondern: Welche Benutzergruppe bekommt welchen Mechanismus? Wer diese Entscheidung früh und bewusst trifft, baut eine BTP-Berechtigungsarchitektur, die mit der Landschaft wächst, Audits standhält und im Tagesgeschäft wenig Pflege braucht — statt später unter Zeitdruck umbauen zu müssen.

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.