Identity Management verbindet Menschen, Anwendungen und Plattformen über nachvollziehbare Identitäten und Zugriffe. Der Einstieg ist deshalb eine Organisationsfrage: Wer benötigt wofür Zugang, wer genehmigt ihn und wann endet er? Ein neues Anmeldeportal allein beantwortet diese Fragen noch nicht.
Identität prüfen, Rechte gezielt vergeben
Authentifizierung prüft, wer sich anmeldet. Autorisierung entscheidet, welche Daten und Funktionen diese Identität nutzen darf. Ein Identity Provider kann eine Anmeldung für mehrere Anwendungen übernehmen; die fachliche Berechtigungsprüfung muss trotzdem in den angebundenen Systemen durchgesetzt werden. OpenID Connect beschreibt die Übermittlung und Prüfung von Identitätsinformationen [1].
Single Sign-on (SSO) reduziert wiederholte Anmeldungen. Für die Anmeldung sind Mehrfaktor-Authentifizierung (MFA), Wiederherstellungswege und kontrollierte Notfallzugänge zu planen. Dabei zählt auch, ob kritische Aktionen eine erneute Prüfung erfordern. Ein verlorenes Gerät darf weder unkontrollierten Zugang noch einen dauerhaften Ausschluss auslösen.
Eintritt, Wechsel und Austritt durchgängig regeln
Der Lebenszyklus beginnt mit einer verlässlichen Quelle, etwa dem Personalverwaltungssystem oder einem gepflegten Verzeichnis. Beim Eintritt werden erforderliche Zugänge vergeben. Bei einem Aufgabenwechsel werden neue Rechte ergänzt und bisherige geprüft. Beim Austritt werden Zugänge entzogen. Diese Phasen heißen Joiner, Mover und Leaver [2].
Für jeden Übergang braucht es einen Auslöser, eine verantwortliche Stelle und eine Kontrolle im Zielsystem. Ein gesperrtes zentrales Konto beendet nicht automatisch jede bestehende Sitzung. Anwendungen, Tokens und lokale Konten müssen im Entzugsverfahren berücksichtigt werden. Auch Gäste und zeitlich begrenzte Projektzugänge brauchen ein Ablaufdatum und eine zuständige Person.
Anmeldung und Kontenbereitstellung unterscheiden
Für die Anbindung sind unterschiedliche Protokolle relevant. OpenID Connect und SAML ermöglichen föderierte Anmeldung; die Zielanwendung vertraut dabei den geprüften Informationen eines Identitätsdienstes [1][3]. SCIM beschreibt Schnittstellen, über die Identitätsdaten wie Benutzer und Gruppen angelegt, geändert oder entfernt werden können [4].
Eine SSO-Anbindung bedeutet deshalb noch keine automatische Kontenpflege. Vor der Auswahl ist je Anwendung zu prüfen, welche Protokolle, Attribute und Entzugsfunktionen sie tatsächlich unterstützt. Wo eine Integration fehlt, braucht es einen dokumentierten Ersatzprozess mit kontrollierbarer Erledigung.
Rollen und technische Identitäten begrenzen
Rollen sollten fachliche Aufgaben abbilden und Zugriffe nachvollziehbar bündeln. Für sensible Rechte gehören Genehmigung, begrenzte Gültigkeit und regelmäßige Prüfung dazu. Zu viele pauschale Rollen verschieben die Komplexität lediglich in Ausnahmen.
Anwendungen und Automatisierungen brauchen eigene technische Identitäten mit klarer Zuständigkeit. Sie sollten keine persönlichen Konten gemeinsam verwenden. Ihre Berechtigungen, Zugangsdaten und Laufzeiten sind getrennt zu verwalten; ungenutzte Identitäten müssen erkennbar sein. So lässt sich auch ein Wechsel im Team bewältigen, ohne unbekannte Abhängigkeiten zu hinterlassen.
Auswahl und Betrieb zusammen planen
Keycloak, ZITADEL oder Microsoft Entra ID können je nach Umgebung Bausteine sein. Entscheidend sind die vorhandenen Anwendungen, Nutzergruppen, Integrationsmöglichkeiten und das gewünschte Betriebsmodell. Funktionsumfang und Betriebsverantwortung sollten anhand der benötigten Edition und Bereitstellung geprüft werden.
Zur Entscheidung gehören Updates, Verfügbarkeit, Protokollierung, Schlüsselwechsel und Wiederherstellung. Ein Pilot sollte Anmeldung, Rollenwechsel und vollständigen Entzug in ausgewählten Anwendungen durchspielen. Das Ergebnis ist eine überprüfbare Integrationsentscheidung mit bekannten Grenzen.
Was Sie zuerst entscheiden können
- Welche Quelle Identitäten und Änderungen verlässlich liefert.
- Wer Rollen genehmigt, überprüft und wieder entzieht.
- Welche Anwendungen zuerst angebunden werden und wie der Entzug nachgewiesen wird.
- Wer den Identitätsdienst betreibt und bei Ausfällen handlungsfähig bleibt.
Quellen
- OpenID Connect Core 1.0OpenID Foundation
- What are lifecycle workflows?Microsoft Learn
- SAML 2.0 Technical OverviewOASIS
- RFC 7644: SCIM ProtocolIETF