Who is allowed to do what — and how do we know?

Why IAM is critical for digitalisation

Every digital initiative starts with a single question: who is using the system, and what are they allowed to do? Without a clean answer you get shadow IT, manual approval workflows, brittle permission matrices — and in the worst case privacy incidents that stop the project cold.

Identity & Access Management is the layer that manages identities, authenticates them and authorises their actions — consistently, across applications. Done well, IAM is invisible. Done badly, it blocks innovation for years.

In regulated industries and the public sector, IAM is also a compliance question. BaFin supervision, ISO 27001, GDPR and the OZG demand traceable access decisions, separation of duties and an audit trail.

The standards you should know

IAM lives on standards. Three are essential — and it pays to know which one is the right tool for the job.

Other relevant building blocks

SCIM (user provisioning across systems) · FIDO2/WebAuthn (passwordless, phishing-resistant authentication) · mTLS (mutual certificate validation for sensitive M2M traffic) · JWT (compact, signed token format).

Tutorial: setting up Keycloak as open-source IAM

Keycloak is the de-facto open-source standard for IAM. This walk-through takes you from container start to a production-ready integration — deliberately compact, but with the levers that actually matter in real projects.

1. Prerequisites

   A Linux machine (or macOS/WSL2) with Docker or Podman. For production: PostgreSQL as an external database, a reverse proxy with TLS (e.g. nginx or Traefik), and a DNS entry for the Keycloak URL.

2. Run Keycloak in a container

   For local development a single container in dev mode is enough. Note: dev mode is not suitable for production.

   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
   
   # Then open http://localhost:8080 → Administration Console

3. Create a realm

   A realm is an isolated tenant unit (own users, clients, roles). Use the master realm only for admin tasks — put everything domain-related into its own realm, e.g. "city-anytown".

   # Via UI: top-left → "Create Realm"
   # Or via Admin CLI:
   kcadm.sh config credentials --server http://localhost:8080 \
       --realm master --user admin --password admin
   kcadm.sh create realms -s realm=city-anytown -s enabled=true

4. OIDC client for your application

   Each integrated application is registered as a "client". For a web app pick the standard "Authorization Code with PKCE" flow — secure and suitable for both SPAs and server apps.

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

5. Roles and groups

   Model permissions along business roles ("clerk", "manager", "read-only"). Groups aggregate roles and simplify joiner/mover/leaver — new staff inherit access through group membership.

6. Wire up your application (Spring Boot example)

   With Spring Security OAuth2 Client, configuration is enough. Token validation and login redirect are handled by the framework.

   # application.yml
   spring:
     security:
       oauth2:
         client:
           registration:
             keycloak:
               client-id: citizen-portal
               client-secret: ${KC_SECRET}
               scope: openid, profile, email
           provider:
             keycloak:
               issuer-uri: https://iam.anytown.gov/realms/city-anytown

7. Production hardening

   For production switch to: PostgreSQL backend, external TLS termination (set hostname and proxy address forwarding), high availability via cluster, brute-force protection enabled, password policy, MFA via TOTP or WebAuthn, regular backups and monitoring for login anomalies.

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

BUND ID — the federal citizen identity

BUND ID is the central, cross-sector user account for online government services in Germany. For municipalities offering OZG services, it isn't an add-on — it's the expected entry point.

Behind BUND ID sits a federal Identity Provider that authenticates citizens at multiple trust levels — from simple username/password to the eID function of the German national ID card. Municipalities integrate BUND ID via SAML or OIDC; authentication happens at the federal IdP, the result is signed and handed over to the line-of-business system.

Trust levels follow eIDAS: low (basic account), substantial (ELSTER certificate) and high (eID / national ID card). The required level depends on the service — a defect-reporting tool may live with "low", a building permit needs "high".

For implementation we recommend: integrate BUND ID as an external Identity Provider in Keycloak (identity brokering), read the trust level from the claims and store it as an attribute in your own system. The line-of-business system stays decoupled — and a future move to e.g. the EUDI Wallet becomes possible without code changes.