Wer darf was — und woher wissen wir das?

Warum IAM für Digitalisierung entscheidend ist

Jede Digitalisierung beginnt mit der Frage: Wer benutzt das System, und welche Rechte hat diese Person? Ohne saubere Antwort entstehen Schatten-IT, manuelle Freischalt-Prozesse, fehleranfällige Berechtigungsmatrizen — und im schlimmsten Fall Datenschutzvorfälle, die Projekte stoppen.

Identity & Access Management (IAM) ist die Schicht, die Identitäten verwaltet, authentifiziert und autorisiert — möglichst konsistent über alle Anwendungen hinweg. Ein gut gebautes IAM ist meist unsichtbar; fehlt es oder ist es schief gebaut, blockiert es Innovation auf Jahre.

Bei regulierten Branchen und im öffentlichen Sektor wird IAM zur Compliance-Frage. BaFin-Aufsicht, ISO 27001, DSGVO und das Onlinezugangsgesetz verlangen nachvollziehbare Zugriffsentscheidungen, Trennung von Pflichten und auditierbare Spuren.

Standards & Protokolle, die Sie kennen sollten

IAM lebt von Standards. Drei sind unverzichtbar — und es lohnt zu wissen, wann welcher Standard das richtige Werkzeug ist.

Weitere relevante Bausteine

SCIM (User-Provisioning zwischen Systemen) · FIDO2/WebAuthn (passwortlose, phishing-resistente Authentifizierung) · mTLS (gegenseitige Zertifikatsprüfung für vertrauliche M2M-Kommunikation) · JWT (kompaktes, signiertes Token-Format).

Tutorial: Keycloak als Open-Source-IAM aufsetzen

Keycloak ist der De-facto-Open-Source-Standard für IAM. Diese Anleitung führt Sie vom Container-Start bis zur produktiven Anbindung — bewusst kompakt, aber mit den Stellschrauben, die in Projekten wirklich relevant sind.

1. Voraussetzungen

   Eine Linux-Maschine (oder macOS/WSL2) mit Docker oder Podman. Für Produktion: PostgreSQL als externe Datenbank, ein Reverse-Proxy mit TLS (z.B. nginx oder Traefik), und ein DNS-Eintrag für die Keycloak-URL.

2. Keycloak im Container starten

   Für lokale Entwicklung reicht ein einzelner Container im dev-Modus. Achtung: dieser Modus ist nicht für Produktion gedacht.

   docker run -d --name keycloak \
     -p 8080:8080 \
     -e KEYCLOAK_ADMIN=admin \
     -e KEYCLOAK_ADMIN_PASSWORD=admin \
     quay.io/keycloak/keycloak:25.0.0 \
     start-dev
   
   # Anschließend: http://localhost:8080 → Administration Console

3. Realm anlegen

   Ein Realm ist eine isolierte Mandanten-Einheit (eigene Nutzer, Clients und Rollen). Den Master-Realm nur für Admin-Aufgaben nutzen — alles Fachliche in einen eigenen Realm, z.B. „kommune-musterstadt“.

   # Über die UI: Top-Left → „Create Realm"
   # Oder per Admin-CLI:
   kcadm.sh config credentials --server http://localhost:8080 \
       --realm master --user admin --password admin
   kcadm.sh create realms -s realm=kommune-musterstadt -s enabled=true

4. OIDC-Client für die Anwendung

   Jede angebundene Anwendung wird als „Client“ registriert. Für eine Web-App den Standard-Flow „Authorization Code mit PKCE“ wählen — sicher und für SPAs wie Server-Apps geeignet.

   {
     "clientId": "buergerportal",
     "protocol": "openid-connect",
     "publicClient": false,
     "standardFlowEnabled": true,
     "redirectUris": ["https://buergerportal.musterstadt.de/*"],
     "webOrigins":   ["https://buergerportal.musterstadt.de"],
     "attributes": {
       "pkce.code.challenge.method": "S256"
     }
   }

5. Rollen und Gruppen

   Berechtigungen entlang fachlicher Rollen modellieren („sachbearbeiter", „leitung", „lesend"). Gruppen aggregieren Rollen und vereinfachen Joiner/Mover/Leaver — neue Mitarbeiter erben Zugriffe per Gruppenmitgliedschaft.

6. Anwendung anbinden (Spring-Boot-Beispiel)

   Mit dem Spring-Security-OAuth2-Client genügt eine Konfiguration. Token-Validierung und Login-Redirect übernimmt das Framework.

   # application.yml
   spring:
     security:
       oauth2:
         client:
           registration:
             keycloak:
               client-id: buergerportal
               client-secret: ${KC_SECRET}
               scope: openid, profile, email
           provider:
             keycloak:
               issuer-uri: https://iam.musterstadt.de/realms/kommune-musterstadt

7. Produktiv schalten — Hardening

   Für Produktion umstellen auf: PostgreSQL-Backend, externe TLS-Terminierung (Hostname und Proxy-Address-Forwarding setzen), Hochverfügbarkeit per Cluster, Brute-Force-Schutz aktivieren, Passwort-Policy, MFA über TOTP oder WebAuthn, regelmäßige Backups und Monitoring auf Anmelde-Anomalien.

   kc.sh start \
     --hostname=iam.musterstadt.de \
     --proxy-headers=xforwarded \
     --http-enabled=true \
     --db=postgres \
     --db-url=jdbc:postgresql://db:5432/keycloak \
     --db-username=keycloak \
     --db-password=${DB_PASSWORD}
   
   # Plus: Brute-Force-Detection in Realm-Settings → Security Defenses

BUND ID — die föderale Bürgeridentität

Die BUND ID ist das zentrale, sektorenübergreifende Nutzerkonto für Online-Verwaltungsleistungen in Deutschland. Für Kommunen, die OZG-Leistungen anbieten, ist sie kein Add-on, sondern die erwartete Eintrittstür.

Hinter der BUND ID steht ein föderaler Identity Provider, der Bürger:innen über mehrere Vertrauensniveaus authentifiziert — von einfachem Benutzername/Passwort bis hin zur Online-Ausweis-Funktion (eID) des Personalausweises. Kommunen integrieren die BUND ID per SAML oder OIDC; die Authentifizierung passiert beim föderalen IdP, das Ergebnis wird signiert an das Fachverfahren übergeben.

Vertrauensniveaus richten sich nach eIDAS: niedrig (Benutzerkonto), substanziell (ELSTER-Zertifikat) und hoch (eID/Online-Ausweis). Welches Niveau eine Leistung verlangt, bestimmt die Fachlichkeit — ein Mängelmelder reicht mit „niedrig", ein Bauantrag verlangt „hoch".

Für die Implementierung empfehlen wir: BUND ID als externen Identity Provider in Keycloak einbinden (Identity Brokering), das Niveau aus den Claims auslesen und im eigenen System als Attribut speichern. So bleibt das Fachverfahren entkoppelt — und ein späterer Wechsel der Bürgeridentität (z.B. EUDI-Wallet) wird ohne Code-Änderung möglich.