SSO für interne Apps: SAML-/OIDC-Claims auf Rollen und Teams abbilden

Warum Claim-Mapping für interne Apps wichtig ist

Single Sign-On klingt einfach: auf "Mit Okta anmelden" oder "Mit Azure AD anmelden" klicken und fertig. Die Schwierigkeit beginnt danach. Ohne klares Claim-Mapping erhalten Menschen zu viel Zugriff (ein Support-Mitarbeiter sieht die Gehaltsabrechnung) oder zu wenig Zugriff (ein neuer Mitarbeiter kann am ersten Tag das benötigte Tool nicht öffnen).

Interne Apps sind komplizierter als öffentliche Apps, weil sie teamsübergreifend genutzt werden und sich ständig ändern. Ein einziges Tool wird gleichzeitig von Support, Finance und Sales verwendet. Organigramme verschieben sich, externe Mitarbeitende kommen und gehen, und Teams werden umbenannt oder aufgespalten. Wenn Zugriffsregeln nur im Kopf existieren, kopiert SSO dieses Durcheinander direkt in Ihre App.

Claim-Mapping ist der Weg, Identitätsdaten vom Identity Provider (IdP), wie Gruppen, Abteilung oder Jobtitel, in Berechtigungen zu übersetzen, die Ihre App versteht. Das bedeutet in der Regel, dass Sie entscheiden:

• Welche Rollen es in der App gibt (Admin, Manager, Viewer etc.)
• Zu welchen Teams oder Workspaces Nutzer gehören
• Was jede Rolle tun kann und welche Sicht jedes Team hat
• Wer automatisch Zugriff erhält und wer eine Genehmigung braucht

Zwei Risiken verursachen die meisten Probleme:

• Falsche Zuordnungen. Ein Gruppenname passt zur falschen Rolle oder eine weit gefasste "Alle Mitarbeitenden"-Gruppe gewährt versehentlich Admin-Rechte.
• Fehlende Claims. Der IdP sendet für manche Nutzer keine Gruppen, ein Attribut ist leer oder das Token ist zu groß und wird abgeschnitten.

Ihre App braucht sichere Defaults, damit fehlende oder unerwartete Daten nie zu versehentlichem Zugriff führen.

SAML vs. OIDC-Claims in einfachen Worten

Bei einer SSO-Anmeldung sendet Ihr IdP Ihrer App ein kleines Paket an Fakten über den Nutzer. Jedes Faktum ist ein Claim, im Grunde ein beschriftetes Feld wie "email = [email protected]" oder "department = Finance".

SAML und OIDC können ähnliche Fakten übertragen, verpacken sie aber unterschiedlich.

SAML ist in älteren Enterprise-Setups verbreitet. Es sendet meist ein XML-Dokument (eine Assertion) mit Attributen. Diese Attribute sind die Claims, die Ihre App liest.

OIDC ist neuer und baut auf OAuth 2.0 auf. Es sendet typischerweise ein signiertes JSON-Token (ID-Token) plus optional User-Info, wobei die Felder im Token die Claims sind.

Für interne Apps interessieren Sie sich meistens für eine kleine Menge an Claims:

• E-Mail-Adresse
• Eine stabile Nutzer-ID vom IdP (subject)
• Vollständiger Name (oder Vor- und Nachname)
• Gruppenmitgliedschaften (Teams, Security-Gruppen)
• Abteilung oder Jobtitel

Eine Unterscheidung verhindert viel Verwirrung:

Authentifizierung beantwortet "Wer ist dieser Nutzer?" Claims wie eine stabile Nutzer-ID und E-Mail helfen dabei, das SSO-Login mit dem richtigen Konto zu verknüpfen.

Autorisierung beantwortet "Was darf der Nutzer tun?" Claims wie Gruppen oder Abteilung helfen dabei, den Nutzer in Rollen und Teams der App zu mappen.

Zwei Personen können sich erfolgreich authentifizieren, aber nur diejenige mit einem "Finance"-Gruppen-Claim sollte Zugriff auf eine Abrechnungsseite erhalten.

Rollen und Teams: Entscheiden, worauf Sie mappen

Bevor Sie SAML-Attribute mappen oder OIDC-Claims in Berechtigungen umwandeln, klären Sie zwei verschiedene Dinge, die Ihre App wissen muss:

• Rollen definieren, was jemand tun kann (Berechtigungen).
• Teams definieren, wo jemand hingehört (Scope).

Rollen beantworten Fragen wie: Kann diese Person ansehen, bearbeiten, genehmigen, exportieren, Nutzer verwalten oder Einstellungen ändern?

Teams beantworten Fragen wie: In welcher Abteilung, Region, Queue oder Kostenstelle arbeitet diese Person, und welche Datensätze soll sie sehen?

Halten Sie Rollen klein und stabil. Die meisten internen Apps brauchen nur wenige Rollen, die selten geändert werden, selbst wenn sich Personen intern verschieben. Teams sollten die tägliche Realität abbilden: Support Tier 2, EMEA-Abdeckung, eine temporäre Queue-Verantwortung.

Das Prinzip der geringsten Rechte ist die sicherste Vorgabe. Viele interne Apps kommen mit drei Rollen aus:

• Viewer: kann Daten lesen und Suchen ausführen
• Editor: kann Datensätze erstellen und aktualisieren
• Admin: kann Einstellungen, Nutzer und Zugriffsregeln verwalten

Schreiben Sie in einfacher Sprache nieder, was jede Rolle erlaubt. Das verhindert "Überraschungs-Admin"-Zugriff, wenn sich ein Gruppenname ändert, und vereinfacht spätere Überprüfungen.

Gruppenbasiertes Zugriffsmodell: Wie man über IdP-Gruppen nachdenkt

Gruppenbasiertes Zugriffsmanagement bedeutet, dass Ihre App Berechtigungen nicht Nutzer für Nutzer festlegt. Stattdessen pflegt der IdP die Gruppenmitgliedschaften, und Ihre App mappt diese Gruppen auf Rollen und Teams.

Beginnen Sie damit zu entscheiden, was eine Gruppe gewährt. In vielen Tools mappt eine Gruppe auf genau eine Rolle (z. B. "Support Agent") und optional ein Team (z. B. "Tier 2"). Wichtig ist, dass die Zuordnung langweilig und vorhersehbar bleibt: dieselbe Gruppe bedeutet immer denselben Zugriff.

Wenn Nutzer in mehreren Gruppen sind

Menschen gehören oft zu mehr als einer IdP-Gruppe. Sie brauchen eine Regel zur Auflösung dieser Fälle, und sie sollte stabil bleiben.

Gängige Ansätze:

• Additive Regeln: Berechtigungen aus allen passenden Gruppen kombinieren (funktioniert, wenn Berechtigungen eng gefasst sind)
• Prioritätsregeln: Die Gruppe mit der höchsten Priorität auswählen und die anderen ignorieren (nützlich bei widersprüchlichen Rollen)
• Hybrid: additiv für Teams, Priorität für Rollen

Was auch immer Sie wählen, dokumentieren Sie es. Eine spätere Änderung kann Nutzer plötzlich mehr oder weniger berechtigen.

Verwenden Sie eine skalierbare Namenskonvention

Klare Gruppennamen reduzieren Fehler und erleichtern Audits. Ein praktisches Muster ist:

• --

Zum Beispiel support-tool-prod-agent oder finance-tool-staging-viewer. So vermeiden Sie vage Namen wie "Admins", die in mehreren Apps wiederverwendet werden. Wenn ein Nutzer zu keiner relevanten Gruppe gehört, standardisieren Sie auf keinen Zugriff (oder einen klar begrenzten Gaststatus) und zeigen Sie eine Erklärung, wie Zugriff angefordert werden kann.

Kontoverknüpfung: SSO-Nutzer mit App-Konten abgleichen

SSO beweist, wer jemand ist, aber Ihre App muss entscheiden, welchem bestehenden Konto diese Identität zugeordnet wird. Ohne Account Linking kann dieselbe Person im Lauf der Zeit mehrere Konten erhalten, weil Identifikatoren wechseln: neue E-Mail, Namensänderungen, Wechsel zwischen Tochtergesellschaften oder IdPs.

Wählen Sie einen stabilen, eindeutigen Schlüssel als primären Match.

• Bei OIDC ist das oft der IdP-sub-Claim.
• Bei SAML ist es häufig eine persistente NameID oder ein dediziertes, unveränderliches Benutzerattribut.

Speichern Sie diesen Wert als "IdP user ID" zusammen mit der IdP-Issuer/Entity-ID, damit derselbe sub von einem anderen IdP nicht kollidiert.

E-Mail ist nützlich, aber behandeln Sie sie als Komfortschlüssel, nicht als Quelle der Wahrheit. E-Mails ändern sich bei Umbenennungen, Domain-Migrationen oder Fusionen. Aliasse und gemeinsame Postfächer können ebenfalls zu überraschenden Treffern führen. Wenn Sie per E-Mail abgleichen, tun Sie das nur mit verifiziertem IdP-Signal und erwägen Sie einen einmaligen Bestätigungs-Schritt.

Beim ersten Login wählen die meisten internen Tools ein Onboarding-Muster:

• Auto-Create: Konto sofort anlegen und minimale Berechtigungen vergeben.
• Invite-only: Logins nur für vorab erstellte (oder genehmigte) Nutzer erlauben.
• Approval-Flow: Konto anlegen, aber Zugriff blockieren, bis ein Manager oder Admin Rolle/Team bestätigt.

Eine sichere Voreinstellung ist Auto-Create ohne Berechtigungen, dann Zugriff basierend auf Gruppen oder einem Genehmigungsschritt vergeben.

Schritt für Schritt: Claims auf Rollen und Teams abbilden

Gutes Claim-Mapping macht SSO unsichtbar: Leute melden sich an und landen am richtigen Ort mit den passenden Rechten.

Beginnen Sie damit, Ihr Zugriffsmodell in einfacher Sprache zu dokumentieren. Listen Sie jede Rolle (Viewer, Agent, Manager, Admin) und jedes Team (Support, Finance, IT) auf, plus wer sie bekommen sollte und warum.

Bestätigen Sie dann, was Ihr IdP tatsächlich senden kann. Für SAML oder OIDC möchten Sie typischerweise eine stabile Nutzer-ID (subject oder NameID), E-Mail und ein oder mehrere Gruppenattribute. Erfassen Sie die exakten Gruppenwerte so, wie sie erscheinen, einschließlich Groß-/Kleinschreibung und Präfixen. "Support" und "support" sind nicht dasselbe.

Ein praktischer Ablauf:

• Definieren Sie Rollen und Teams und benennen Sie einen Eigentümer für jede Zuordnung (jemand, der Änderungen genehmigen kann).
• Listen Sie verfügbare Claims und die exakten Gruppennamen aus dem IdP auf, inklusive Randfälle (externe Mitarbeitende, gemeinsame Postfächer).
• Schreiben Sie Mapping-Regeln: Gruppe-zu-Rolle, Gruppe-zu-Team und eine Überschreibungsreihenfolge, wenn mehrere Gruppen passen.
• Testen Sie mit 3 bis 5 realen Nutzertypen (Neuer Mitarbeiter, Manager, Vertragspartner, Admin) mit echten IdP-Konten.
• Für jeden Testnutzer schreiben Sie zuerst das erwartete Rolle/Team-Ergebnis, dann melden Sie sich an und vergleichen.

Halten Sie ein kleines Beispiel bereit, um Regeln greifbar zu machen. Wenn ein Nutzer in "okta-support" ist, wird er Team Support und Rolle Agent. Wenn er außerdem in "okta-support-managers" ist, überschreibt die Manager-Rolle Agent.

Fügen Sie schließlich eine einfache Debug-Möglichkeit hinzu. Loggen Sie die rohen erhaltenen Claims (sicher), die Regeln, die gegriffen haben, und das finale Rolle/Team-Ergebnis. Wenn jemand sagt: "Ich habe mich angemeldet, kann mein Tool aber nicht sehen", wird daraus keine Rätselrunde, sondern ein kurzer Check.

Sichere Voreinstellungen, wenn Claims fehlen

Fehlende Claims sind normal. Der IdP sendet möglicherweise für Service-Accounts keine Gruppen, ein Connector lässt ein Feld weg oder ein Nutzer ist mitten in einer Migration. Behandeln Sie "keine Daten" als "kein Vertrauen".

Die sicherste Vorgabe ist deny-by-default: keine Rolle, kein Team, kein Zugriff. Wenn Sie zwingend Zugang erlauben müssen, damit jemand Zugriff anfordern kann, halten Sie ihn schreibgeschützt und klar eingeschränkt.

Wählen Sie ein Verhalten und dokumentieren Sie es:

• Login blockieren mit einer klaren Nachricht: "Ihr Konto hat keinen zugewiesenen Zugriff. Kontaktieren Sie den Support."
• Eingeschränkten Zugriff erlauben mit Warnung und Deaktivierung sensibler Aktionen.
• Den Nutzer anlegen, aber keine Rolle oder kein Team zuweisen, bis sie genehmigt werden.

Geben Sie niemals temporär Admin-Rechte als Default.

Planen Sie für Teildaten. Wenn Sie eine E-Mail aber keine Gruppen bekommen, können Sie dennoch ein Konto anlegen und zur Genehmigung weiterleiten. Wenn Sie Gruppen, aber keine stabile Kennung erhalten, vermeiden Sie Auto-Linking zu einem bestehenden Konto, da das die falsche Person anheften kann.

Haben Sie einen Eskalationsweg für Fehlerfälle:

• Einen benannten Eigentümer (IT oder App-Admin), der Zugriff genehmigen kann
• Einen manuellen Rollen-Zuweisungsfluss mit Audit-Notiz
• Eine Möglichkeit, Claims beim nächsten Login erneut zu prüfen
• Eine Frist für "pending access"-Konten

Änderungen, Entzug und Offboarding handhaben

Menschen wechseln Teams, ändern Manager oder verlassen das Unternehmen. Ihre SSO-Konfiguration sollte das als normal behandeln.

Wenn sich jemand in ein anderes Team bewegt, aktualisieren Sie den Zugriff beim nächsten Login: Claims neu auswerten und das aktuelle Mapping anwenden. Vermeiden Sie "sticky" Zugriffe, die ewig bestehen, nur weil sie einmal gewährt wurden.

Abgänge sind anders. Auf den nächsten Login zu warten reicht nicht. Zugriff sollte schnell enden, auch wenn noch aktive Sessions existieren. Das bedeutet in der Regel, das Konto im IdP zu deaktivieren; Ihre App sollte eine deaktivierte oder fehlende Identität sofort blockieren.

Deprovisioning sollte vorhersehbar sein: Konto deaktivieren, Teammitgliedschaften entfernen und Audit-Daten aufbewahren. Oft müssen Sie Genehmigungen, Kommentare und Historie für Compliance erhalten, während neue Aktionen blockiert werden.

Vertragspartner und zeitlich begrenzter Zugriff verdienen besondere Aufmerksamkeit. Legen Sie sie in zeitlich begrenzte Gruppen im IdP oder hängen Sie ein Ablaufdatum an ihre Rolle, sodass Zugriff nach Projektende nicht hängen bleibt.

Eine praktische Offboarding-Policy:

• Claims bei jeder Anmeldung erneut prüfen und Team-Mitgliedschaft aus dem IdP aktualisieren
• Wenn ein Nutzer aus erforderlichen Gruppen entfernt wird, Privilegien sofort entziehen (nächster Login oder nächster Sync)
• Konto deaktivieren und Audit-Trails sowie Eigentumshistorie erhalten
• Für Vertragspartner ein Enddatum verlangen und vor Verlängerung prüfen
• Regelmäßige Zugriffsüberprüfungen für sensible Rollen wie Finance oder Admin durchführen

Häufige Fehler und Fallstricke

Die meisten SSO-Ausfälle entstehen nicht, weil SAML oder OIDC "kompliziert" wären. Sie passieren, weil die App unsichere Annahmen über Personen, Gruppen und Identifikatoren trifft.

Ein häufiger Fehler ist, Rollen- und Team-Mapping zu vermischen. Rollen sind "was darf jemand tun?" Teams sind "wo gehört jemand hin?" Wenn Sie eine Team-Gruppe direkt auf eine mächtige Rolle wie Admin abbilden, vergeben Sie oft weiten Zugriff an jeden, der zufällig in diesem Team ist.

Ein weiterer Fallstrick ist, E-Mail als einzigen Identifier zu nutzen. E-Mails ändern sich, und Aliasse können Duplikate erzeugen. Bevorzugen Sie eine stabile IdP-Nutzer-ID (z. B. sub/NameID) als Primärschlüssel und behandeln Sie E-Mail als Anzeige- und Benachrichtigungsfeld.

Weitere häufige Probleme:

• Offenfallen, wenn Gruppen fehlen (stattdessen auf keinen oder nur niedrigen Zugriff setzen)
• Unklare Gruppennamen, die zwischen Dev, Staging und Prod wiederverwendet werden
• Gruppenmitgliedschaft als reine Berechtigungsliste behandeln, ohne zu prüfen, was jede Gruppe wirklich bedeutet
• Nicht mit Multi-Team-Nutzern umgehen, die Zugriff in mehreren Bereichen brauchen, ohne Admin zu werden
• Partner und Vertragspartner vergessen, die vom Mitarbeiter-Only-Zugriff isoliert sein sollten

Testen Sie Randfälle vor dem Livegang. Ein Finance-Analyst in der Incident-Response könnte zwei Teams und eine erhöhte Rolle brauchen. Wenn Ihre Regeln nur ein Team erlauben, verliert er entweder Zugriff oder bekommt zu viele Rechte.

Schnelle Checkliste vor dem Livegang

Bevor Sie SSO für alle aktivieren, machen Sie einen Testlauf mit ein paar Testkonten aus jedem Team. Die meisten Zugriffsprobleme zeigen sich sofort, wenn Sie einen neuen Mitarbeiter, einen Rollenwechsel und ein Offboarding testen.

Beginnen Sie mit dem Account Linking. Wählen Sie einen eindeutigen Identifier, der sich nicht ändert; bei OIDC ist das meist sub, bei SAML oft NameID oder ein spezielles unveränderliches Attribut.

Entscheiden Sie als Nächstes, was passiert, wenn Claims fehlen. Die sicherste Voreinstellung ist, keinen erhöhten Zugriff (und in vielen Apps gar keinen Zugriff) zu gewähren, wenn Gruppen- oder Rollen-Claims fehlen oder leer sind. Stellen Sie sicher, dass Sie mindestens eine niedrigprivilegierte Rolle haben, die Menschen hereinlässt, ohne sensible Aktionen freizugeben, falls das zu Ihrem Workflow passt.

Eine einfache Pre-Launch-Checkliste:

• Bestätigen Sie, dass Ihr Linking-Identifier stabil und eindeutig ist (und in Logs sichtbar)
• Verifizieren Sie, dass fehlende Gruppen-Claims keinen Zugriff über eine niedrigprivilegierte Rolle hinaus gewähren
• Admin-Zugriff nur über eine explizite Admin-Gruppe und zusätzlich einen zweiten Genehmigungsschritt (auch manuell) erlauben
• Entfernen testen: Wenn ein Nutzer eine Gruppe verlässt, fällt der Zugriff beim nächsten Login (oder beim nächsten Sync)
• Mapping-Regeln so dokumentieren, dass ein Kollege sie auf einer Seite verstehen kann

Beispiel: Ein Support- und Finance-Tool mit SSO-Gruppen

Stellen Sie sich ein Operationstool vor, das täglich von Support, Finance und einigen Managern genutzt wird. Sie möchten, dass sich Leute anmelden und sofort die richtigen Bildschirme und Aktionen sehen, ohne dass ein Admin Konten manuell korrigiert.

Erstellen Sie ein paar IdP-Gruppen und mappen Sie sie auf In-App-Rollen und Teams:

• ops-support -> Rolle: Support Agent, Team: Support
• ops-finance -> Rolle: Finance Analyst, Team: Finance
• ops-managers -> Rolle: Manager, Team: Management

So läuft es in der Praxis ab.

Jetzt ein Fall mit E-Mail-Änderung: Omar wechselt von [email protected] zu [email protected]. Weil die App Konten mit der stabilen IdP-Nutzer-ID verknüpft (wie sub bei OIDC oder eine persistente NameID bei SAML) statt mit der E-Mail, entsteht kein Duplikatkonto. Er behält seine Historie und Audit-Trail.

Um Zugriff ohne Rätsel zu verifizieren, halten Sie eine "effective access"-Ansicht bereit, die die verknüpfte IdP-Identität, die empfangenen Gruppen, die resultierende Rolle und das Team zeigt. Wenn etwas falsch aussieht, erkennen Sie schnell, ob es am IdP, an der Mapping-Regel oder an fehlenden Claims liegt.

Nächste Schritte: Zugriff vorhersehbar halten, während sich die Organisation ändert

Die größte Herausforderung ist nicht der Start. Es ist, den Zugriff nach Umstrukturierungen, neuen Teams und "temporären" Ausnahmen überschaubar zu halten.

Pflegen Sie ein einseitiges Mapping-Dokument, das beantwortet:

• Welche IdP-Gruppen auf welche App-Rollen und -Teams mappen
• Was die Default-Reaktion ist, wenn ein Claim fehlt (und wer Änderungen genehmigt)
• Wer jede Hochrisiko-Rolle besitzt (Finance-Admin, User-Admin, Datenexport)
• Wie Vertragspartner und Service-Accounts gehandhabt werden
• Wo die Quelle der Wahrheit liegt (IdP vs. App)

Starten Sie mit einer kleinen Pilotgruppe, die klare Grenzen hat, beheben Sie Randfälle und erweitern Sie dann, ohne neue Regeln zu erfinden. Setzen Sie wiederkehrende Reviews für sensiblen Zugriff an: monatlich für Admin- und Hochrisiko-Rollen, vierteljährlich für normale Rollen.

Wenn Sie die interne App selbst bauen, hilft es, Rollen, Teams und Business-Logik eng zusammenzulegen, damit Änderungen leicht testbar sind. AppMaster (appmaster.io) ist eine Option für Teams, die Rollen und Workflows visuell modellieren und echten Backend-, Web- und Mobile-Code generieren möchten, ohne viele Einzelanpassungen bei Berechtigungen zu pflegen.