badge Identität & Zugang (IAM)feedback
Dieser Funktionsbaustein wird aktiv weiterentwickelt. Neue Funktionen aus den Bereichen EUDI Wallet, Machine Identity und Zero-Trust sind geplant oder in Umsetzung.
Erstellt am: 12. März 2026 | Autor: BMDS-Architekturteam
help Warum ist dieser Baustein für eine Enterprise-Architektur unverzichtbar?feedback
Ohne eine zentrale, föderierte Identitäts- und Zugangssteuerung können Behörden keine sicheren digitalen Dienste betreiben. Jede Fachanwendung müsste ihre eigene Nutzerverwaltung, Authentifizierung und Autorisierung implementieren. Das führt zu Datensilos, Sicherheitslücken und einer schlechten Nutzererfahrung. In einer Enterprise-Architektur ist IAM das Fundament, auf dem alle anderen Bausteine aufbauen:
- Rechtskonformität: Die DSGVO, das OZG und die eIDAS-Verordnung verlangen nachweisbare Identitätsprüfung und datenschutzkonforme Zugriffskontrolle.
- Single Sign-On (SSO): Mitarbeitende und Bürger:innen müssen sich nur einmal anmelden, um auf alle angebundenen Dienste zugreifen zu können.
- Zero-Trust-Sicherheitsmodell: IAM liefert die Grundlage für identitätsbasierte Autorisierung, die im Zero-Trust-Ansatz verankert ist.
- Interoperabilität: Föderierte Identitäten ermöglichen Behörden-übergreifende Zusammenarbeit ohne redundante Nutzerverwaltung.
settings Kernfunktionalitätenfeedback
Authentifizierungfeedback
| Funktion | Beschreibung | Standard |
|---|---|---|
| Single Sign-On (SSO) | Einmalige Anmeldung für alle angebundenen Dienste | OIDC, SAML 2.0 |
| Multi-Faktor-Authentifizierung (MFA) | Zweiter Faktor über TOTP, FIDO2 oder eID | FIDO2 / WebAuthn |
| eID-Anbindung | Integration des deutschen Personalausweises (nPA) und der BundID | TR-03124, eIDAS |
| Zertifikatsbasierte Anmeldung | X.509-Zertifikate für Maschine-zu-Maschine-Kommunikation | mTLS |
Autorisierungfeedback
- Role-Based Access Control (RBAC): Zuordnung von Berechtigungen über Rollen (z. B. „Sachbearbeiter:in", „Abteilungsleitung").
- Attribute-Based Access Control (ABAC): Feingranulare Autorisierung anhand von Kontextattributen (Standort, Uhrzeit, Gerät).
- Policy Engine: Zentrale Regelauswertung über Open Policy Agent (OPA) oder vergleichbare Systeme.
- Delegation: Vertretungsregelungen und Berechtigungsweitergabe für Verwaltungsprozesse.
Föderierte Identitätenfeedback
- SAML 2.0 und OpenID Connect (OIDC) zur Anbindung externer Identity Provider (z. B. Landes-IDPs, EU-weite eIDAS-Knoten).
- SCIM (System for Cross-domain Identity Management) zur automatisierten Provisionierung und Deprovisionierung von Benutzerkonten.
- BundID-Integration als zentrale digitale Identität für Bürger:innen im OZG-Kontext.
recommend Technologieempfehlungenfeedback
| Komponente | Empfehlung | Begründung |
|---|---|---|
| Identity Provider | Keycloak | Open Source, OIDC/SAML, aktive Community, BSI-konform einsetzbar |
| Verzeichnisdienst | OpenLDAP / FreeIPA | Etablierte Open-Source-Implementierung für LDAP |
| Policy Engine | Open Policy Agent (OPA) | Deklarative Rego-Policies, Cloud-Native-Integration |
| Zertifikatsmanagement | cert-manager + HashiCorp Vault | Automatisierte X.509-Verwaltung in Kubernetes |
link Bezug zu anderen Bausteinenfeedback
- Ein- und Auszahlung: Zahlungstransaktionen erfordern verifizierte Identitäten und rollenbasierte Freigabeprozesse.
- Workflows: Genehmigungs-Workflows nutzen RBAC-Rollen zur Steuerung von Bearbeitungsschritten.
- E-Signatur: Qualifizierte elektronische Signaturen setzen eine eindeutige Identitätsprüfung voraus.
- API-Management: Das API Gateway delegiert Authentifizierung und Autorisierung an den IAM-Baustein.
- Consent Management: Einwilligungen werden personenbezogen gespeichert und erfordern eine eindeutige Identität.
gavel Relevante Standards und Vorgabenfeedback
- eIDAS-Verordnung (EU) Nr. 910/2014 und eIDAS 2.0
- OAuth 2.0 (RFC 6749) / OAuth 2.1 (Draft). OAuth 2.1 ist die empfohlene Baseline für alle IAM-Integrationen, da es PKCE verpflichtend macht und unsichere Grant Types entfernt.
- RFC 9700: OAuth 2.0 Security Best Current Practice
- BSI TR-03107 (Elektronische Identitäten und Vertrauensdienste)
- BSI TR-03124 (eID-Client)
- DSGVO Art. 5, 25, 32 (Datenschutz durch Technikgestaltung)
- Sicherheitsvorgaben des Portals
update Erweiterungen & Roadmapfeedback
Der Baustein Identität & Zugang wird in folgenden Bereichen erweitert. Die Erweiterungen bauen auf den neuen Bausteinen aus der Übersicht auf.
EUDI Wallet (eIDAS 2.0)feedback
Mit der europäischen Digital Identity Wallet (eIDAS 2.0 / OIDC4VC) entsteht ein neuer Typ von Identitätsträger, der direkt in den IAM-Baustein integriert werden muss:
| Erweiterung | Beschreibung | Neue Standards |
|---|---|---|
| Verifiable Credentials (VC) | Selbstauskunft für Bürger:innen über das EU-Wallet als Identitätsnachweis | OIDC4VC, SD-JWT |
| Wallet-Anbindung an Keycloak | Keycloak erhält ein EUDI-Wallet-Protokoll-Plugin für die VC-Validierung | OpenID4VP |
| Attributs-Selektive Weitergabe | Bürger:innen geben nur die minimal nötigen Attribute frei (Data Minimization) | ISO 18013-5, SD-JWT |
Single Sign-On für Behörden (Behörden-IAM-Föderation)feedback
Der neue Baustein Single Sign-On für Behörden erweitert den bestehenden IAM-Baustein um eine dedizierte Föderationsschicht für Beschäftigte:
- Konnektierung aller Landes-IDPs über eine zentralen Föderations-Hub (SAML/OIDC-Proxy)
- Einheitliche Nutzerverwaltung via SCIM zwischen Bund, Ländern und Kommunen
- Behördenübergreifende Vertreterregelungen mit attributbasierter Delegation
Machine Identity (Workload Identity)feedback
Der neue Baustein Machine Identity ergänzt den IAM-Baustein um die Identitätsverwaltung für Dienste und Workloads:
- SPIFFE/SPIRE für kryptographisch gesicherte Workload-Identitäten in Kubernetes
- mTLS für alle Dienst-zu-Dienst-Verbindungen, bei denen jeder Service sich gegenüber dem anderen ausweist
- Kurzlebige Zertifikate (TTL < 1 h) ersetzen langlebige API-Keys und Service-Account-Tokens
Zero-Trust-Integrationfeedback
Die Zero-Trust-Policy-Engine externalisiert die Autorisierungslogik aus dem IAM-Baustein:
- Kontinuierliche Verifikation: Jeder API-Aufruf wird anhand von Identität, Gerätezustand und Kontext geprüft
- Policy-as-Code (OPA/Cedar): Mandantenspezifische Regelwerke ohne Code-Änderungen deploybar
- Integration mit Gerätemanagement (MDM): Gerätezustand fließt als Attribut in ABAC-Entscheidungen ein