Multi-tenancy et federation avancee 35 min de lecture

Strategies multi-tenant et identity brokering

Multi-tenancy avec Keycloak

Le multi-tenancy isole les donnees et configurations d'identite entre differents clients ou organisations. Keycloak offre plusieurs approches.

Strategie 1 : Un realm par tenant

# Avantages :
# - Isolation totale (users, clients, roles, themes)
# - Configuration independante par tenant
# - Facile a comprendre

# Inconvenients :
# - Ne scale pas au-dela de ~100 realms
# - Gestion complexe (creation, mise a jour)
# - Pas de SSO entre realms par defaut

# Structure
/realms/tenant-acme/     -> Acme Corp
/realms/tenant-globex/   -> Globex Inc
/realms/tenant-initech/  -> Initech Ltd

Strategie 2 : Realm unique avec groupes/attributs

# Avantages :
# - Scale a des milliers de tenants
# - SSO natif entre tenants
# - Gestion simplifiee

# Inconvenients :
# - Isolation logique seulement (pas physique)
# - Mappers et politiques plus complexes

# Organisation
/realms/main/
  groups/
    /tenants/acme/users
    /tenants/acme/admins
    /tenants/globex/users
    /tenants/globex/admins

# Protocol Mapper pour injecter le tenant
# dans le token
{
  "name": "tenant-mapper",
  "protocol": "openid-connect",
  "protocolMapper": "oidc-group-membership-mapper",
  "config": {
    "claim.name": "tenant",
    "full.path": false
  }
}

Identity Brokering

L'identity brokering permet a Keycloak d'agir comme intermediaire entre l'utilisateur et un Identity Provider (IdP) externe.

# Configuration d'un IdP SAML externe
Identity Providers > Add provider > SAML v2.0

# Parametres essentiels
Single Sign-On Service URL: https://idp.externe.com/sso
Single Logout Service URL: https://idp.externe.com/slo
NameID Policy Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Want AuthnRequests Signed: true

# Mappers pour synchroniser les attributs
Mapper Type: Attribute Importer
Attribute Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
User Attribute Name: firstName

Cross-realm trust

# Realm A fait confiance a Realm B via Identity Brokering

# Dans Realm A :
Identity Providers > Add > Keycloak OpenID Connect

Authorization URL: https://keycloak.com/realms/realmB/protocol/openid-connect/auth
Token URL: https://keycloak.com/realms/realmB/protocol/openid-connect/token
Client ID: realm-a-broker
Client Secret: ...

# Mapper pour importer les roles du Realm B
Mapper Type: External Role to Role
External Role: realmB-admin
Role: local-admin

Federation LDAP/AD avancee

# User Federation > Add provider > LDAP

# Mode de synchronisation
Import Mode: OFF (proxy LDAP en temps reel)
Sync Registrations: ON (creer les users dans LDAP)
Edit Mode: WRITABLE (modifications propagees vers LDAP)

# Mappers avances
# - Group LDAP Mapper : synchro bidirectionnelle des groupes
# - Role LDAP Mapper : mapper les groupes LDAP vers des roles
# - MSAD User Account Control : gestion des comptes Active Directory
# - Certificate LDAP Mapper : certificats X.509

# Synchro periodique
Full Sync Period: 86400   # Synchro complete toutes les 24h
Changed Users Sync: 300  # Synchro incrementale toutes les 5min
Conseil : Pour les grandes organisations, privilegiez la strategie mono-realm avec groupes. Pour les SaaS avec isolation stricte requise, utilisez un realm par tenant avec automatisation via l'API Admin.