DevOps Store

Support

🔐 SSO Keycloak : Centraliser l’Authentification de toutes vos Applications

🟡 Niveau : Intermédiaire à Avancé | ⏱️ Lecture : 16 min | 🛠️ Mise en œuvre : 3-6 heures

📚 Prérequis

  • Docker installé et fonctionnel
  • Compréhension des concepts d’authentification (sessions, tokens)
  • Un nom de domaine avec certificat SSL (pour la production)
  • PostgreSQL disponible (recommandé pour la HA)

Combien de formulaires de login différents vos utilisateurs doivent-ils gérer ? Combien de bases de données contiennent des mots de passe hashés ? Le Single Sign-On (SSO) résout ce problème en centralisant l’authentification. Keycloak est la solution open-source de référence pour l’IAM (Identity and Access Management). Découvrons comment il fonctionne et comment l’intégrer.

🤔 Pourquoi Centraliser l’Authentification ?

Sans SSO, chaque application gère ses propres utilisateurs :

  • ❌ L’utilisateur a 10 mots de passe différents
  • ❌ Chaque équipe implémente sa propre auth (avec ses bugs)
  • ❌ Impossible d’appliquer une politique de sécurité uniforme
  • ❌ Onboarding/Offboarding cauchemardesque
  • ❌ Pas de 2FA généralisé

Avec un SSO comme Keycloak :

  • ✅ Un seul login pour toutes les applications
  • ✅ Politiques de mot de passe centralisées
  • ✅ 2FA/MFA en un clic pour tous
  • ✅ Audit trail unifié
  • ✅ Désactivation instantanée d’un compte = accès révoqué partout

🔄 OIDC vs SAML : Quel Protocole Choisir ?

Keycloak supporte les deux standards majeurs. Voici comment choisir :

OpenID Connect (OIDC)

C’est une couche d’identité au-dessus d’OAuth 2.0. C’est le standard moderne.

  • ✅ Simple à implémenter (JSON, REST)
  • ✅ Parfait pour les SPA, applications mobiles, APIs
  • ✅ Tokens JWT auto-suffisants
  • ✅ Support natif dans la plupart des frameworks modernes

Cas d’usage : Applications web modernes, microservices, APIs REST.

SAML 2.0

Standard plus ancien basé sur XML, encore très utilisé en entreprise.

  • ✅ Supporté par les applications legacy (Salesforce, ServiceNow…)
  • ✅ Fédération d’identité entre organisations
  • ❌ Plus complexe à debugger (XML)
  • ❌ Moins adapté aux applications mobiles

Cas d’usage : Intégration avec des SaaS entreprise, fédération inter-entreprises.

Recommandation

Utilisez OIDC par défaut pour les nouvelles applications. Réservez SAML aux intégrations legacy qui l’exigent.

🏗️ Concepts Clés de Keycloak

Flux d'authentification SSO avec Keycloak et OIDC
Flux d’authentification Single Sign-On avec Keycloak

Realm

Un Realm est un espace isolé contenant ses propres utilisateurs, rôles et configurations. C’est comme un tenant dans une application multi-tenant.

  • master : Realm d’administration (ne pas y mettre d’utilisateurs métier)
  • monentreprise : Votre realm de production

Client

Chaque application qui délègue son authentification à Keycloak est un Client. Exemple :

  • Client « app-frontend » (SPA React)
  • Client « app-backend » (API REST)
  • Client « grafana » (Dashboard monitoring)
Rôles et Groupes
  • Roles : Permissions (admin, editor, viewer)
  • Groups : Regroupement d’utilisateurs qui héritent de rôles

🔧 Intégrer Keycloak avec une Application

Exemple avec une Application Node.js (Express)
npm install express-openid-connect

const { auth } = require('express-openid-connect');

const config = {
  authRequired: false,
  auth0Logout: true,
  baseURL: 'https://myapp.example.com',
  clientID: 'my-app-client',
  issuerBaseURL: 'https://keycloak.example.com/realms/monentreprise',
  secret: 'LONG_RANDOM_SECRET'
};

app.use(auth(config));

// Route protégée
app.get('/profile', requiresAuth(), (req, res) => {
  res.send(`Hello ${req.oidc.user.name}`);
});
Exemple avec Nginx (authentification transparente)

Pour protéger des applications qui ne supportent pas OIDC nativement :

location /protected/ {
    auth_request /auth;
    error_page 401 = @error401;
    
    proxy_pass http://backend;
    proxy_set_header X-User $upstream_http_x_user;
}

location = /auth {
    internal;
    proxy_pass http://keycloak:8080/realms/monentreprise/protocol/openid-connect/userinfo;
    proxy_set_header Authorization $http_authorization;
}

location @error401 {
    return 302 https://keycloak.example.com/realms/monentreprise/protocol/openid-connect/auth?...;
}

🔐 Configurer un Realm et des Clients

Via l’Interface Web
  1. Connectez-vous à la console admin : https://keycloak:8443/admin/
  2. Créez un nouveau Realm : monentreprise
  3. Dans le Realm, créez un Client avec : Client ID : my-app, Client Protocol : openid-connect, Access Type : confidential (pour les backends) ou public (pour les SPA), Valid Redirect URIs : https://myapp.example.com/*
  4. Créez des utilisateurs dans Users
  5. Assignez des rôles aux utilisateurs
Via l’API ou Terraform

Keycloak expose une API REST complète. Pour l’Infrastructure as Code, utilisez le provider Terraform Keycloak :

resource "keycloak_realm" "monentreprise" {
  realm   = "monentreprise"
  enabled = true
}

resource "keycloak_openid_client" "myapp" {
  realm_id  = keycloak_realm.monentreprise.id
  client_id = "my-app"
  access_type = "CONFIDENTIAL"
  valid_redirect_uris = ["https://myapp.example.com/*"]
}

🔄 Haute Disponibilité Keycloak

Un Keycloak en single instance est un SPOF. En HA, vous avez besoin de :

1. Base de Données Externe

Keycloak stocke ses données (utilisateurs, sessions) en base. Utilisez PostgreSQL en haute disponibilité (voir notre article précédent).

2. Clustering Keycloak

Keycloak utilise Infinispan pour le cache distribué. Les nœuds se découvrent via :

  • JDBC_PING : via la base de données partagée (recommandé avec Docker)
  • UDP Multicast : en datacenter (problématique en cloud)
3. Load Balancer

HAProxy ou Nginx devant les nœuds Keycloak avec session stickiness.

📊 Intégration LDAP/Active Directory

En entreprise, vos utilisateurs sont souvent dans un annuaire existant. Keycloak peut fédérer :

  • LDAP : OpenLDAP, 389 Directory
  • Active Directory : Microsoft AD
  • Kerberos : Pour l’authentification transparente Windows

Les utilisateurs AD s’authentifient via Keycloak sans migration de données.

🚀 Déployer Keycloak HA en Production

Une installation Keycloak HA de qualité production nécessite :

  • Build d’une image Docker optimisée
  • Configuration du clustering JDBC_PING
  • Connexion à PostgreSQL externe
  • Configuration hostname et HTTPS
  • Tuning JVM et heap
  • Health checks et métriques Prometheus

Notre rôle Ansible automatise tout :

  • ✅ Keycloak 26.0 avec Docker Compose
  • ✅ Image optimisée (démarrage 60% plus rapide)
  • ✅ Clustering JDBC_PING automatique
  • ✅ Scaling horizontal via keycloak_replicas
  • ✅ Compatible avec notre rôle PostgreSQL HA
  • ✅ Documentation Day-1 et Day-2

Prêt à unifier l’authentification de votre SI ? Découvrez notre rôle Ansible keycloak_ha.

Voir le rôle keycloak_ha

📖 Glossaire

  • SSO (Single Sign-On) : Authentification unique permettant d’accéder à plusieurs applications avec un seul login
  • IAM (Identity and Access Management) : Gestion centralisée des identités et des droits d’accès
  • OIDC (OpenID Connect) : Protocole d’authentification moderne basé sur OAuth 2.0, utilisant des tokens JWT
  • SAML : Security Assertion Markup Language, protocole d’authentification basé sur XML utilisé en entreprise
  • Realm : Espace isolé dans Keycloak contenant ses propres utilisateurs, clients et configurations
  • Client : Application qui délègue son authentification à Keycloak
  • JWT (JSON Web Token) : Format de token auto-contenu encodé en JSON et signé cryptographiquement
  • MFA (Multi-Factor Authentication) : Authentification à plusieurs facteurs (mot de passe + SMS/OTP)

Dans le prochain article, nous verrons comment centraliser tous vos logs avec Promtail et Loki. Fini les SSH sur 50 serveurs !

Tags:

, , , , , , , , ,