Contrôler qui accède à quoi, c'est mettre en service un fournisseur d'identité et y brancher ce qui existe déjà. Cette formation vous fait installer Keycloak sur PostgreSQL, y connecter une application en OpenID Connect, fédérer un annuaire LDAP, puis imposer une authentification forte et automatiser le cycle de vie des comptes. Elle s'adresse aux DevSecOps, aux Platform Engineers et aux administrateurs qui doivent brancher un annuaire sur un SSO. Elle part du vocabulaire et vise un fournisseur d'identité exploitable, pas seulement démarré.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer identification, authentification et autorisation, et choisir un modèle d'autorisation (DAC, MAC, RBAC, ABAC).
- Mettre en service Keycloak avec une base PostgreSQL persistante, puis créer un realm, ses utilisateurs, groupes et rôles.
- Brancher une application et une API sur le fournisseur d'identité en OAuth 2 et OpenID Connect, et valider les jetons reçus.
- Fédérer un annuaire LDAP et un fournisseur d'identité partenaire, situer SAML face à OIDC, et dépanner une intégration qui échoue.
- Imposer un second facteur (TOTP) au groupe sensible, situer WebAuthn et les passkeys, résistants au phishing, puis gouverner le cycle de vie des comptes avec SCIM, les Workflows et la revue des accès.
- Exploiter l'ensemble : Keycloak en production, configuration en code, Kubernetes et Vault branchés sur le realm.
Pourquoi l'IAM mérite une formation à part entière ?
Section intitulée « Pourquoi l'IAM mérite une formation à part entière ? »Parce que les accès sont le point d'entrée de presque tous les incidents. Selon le Verizon DBIR 2024, 68 % des violations font intervenir un élément humain non malveillant : erreur d'un utilisateur ou ingénierie sociale réussie, comme un identifiant volé par phishing (rapport). Une étude de Microsoft Research (2023), menée sur des comptes Entra ID présentant une activité suspecte, mesure que le MFA réduit de 99,22 % le risque de compromission d'un compte (étude). Un IAM bien configuré réduit donc le risque de façon mesurable.
L'IAM ne se limite pas au SSO des utilisateurs. Les identités machines (pipelines, services), la gouvernance des droits dans le temps et l'autorisation fine pèsent autant dans un incident. La formation traite l'identité humaine et le fournisseur d'identité ; l'identité des workloads y figure par une leçon partagée avec la formation Gestion des secrets.
Quels prérequis avant de commencer ?
Section intitulée « Quels prérequis avant de commencer ? »Tout flux d'authentification est une suite de redirections HTTP entre des services joints par leur nom, protégée par TLS et décrite en JSON. Sans ces bases, une erreur de connexion reste un message opaque. Le tableau dit pourquoi chaque prérequis sert ici et où l'apprendre.
| Prérequis | Pourquoi ici | Où l'apprendre |
|---|---|---|
| HTTP : redirections, cookies, en-têtes | OAuth, OIDC et SAML sont des suites de redirections | HTTP et HTTPS |
| TLS et certificats | Les jetons sont signés, l'IdP se sert en HTTPS | Diagnostic TLS |
| DNS et nom d'hôte | Le nom d'hôte est le premier piège de Keycloak | Comprendre le DNS |
| JSON | Jetons, document de découverte, API | Explorer un JSON inconnu |
| Conteneurs et Compose | Tous les exercices tournent en conteneurs | Formation Docker, Docker Compose |
| curl | Observer un flux, appeler une API | curl |
Terraform : init, plan, apply | La leçon sur la configuration du realm en code et l'épreuve du niveau 2 | Le workflow Terraform |
| Pipelines CI : jobs, workflows | La leçon partagée sur l'identité machine s'appuie sur GitHub Actions | Qu'est-ce qu'une pipeline CI/CD ?, Workflows GitHub Actions |
Deux modules demandent en plus des bases que leurs leçons ne reprennent pas : la leçon sur Keycloak et Kubernetes suppose la formation Kubernetes et son RBAC, et le module qui branche la plateforme suppose les bases de Vault, vues dans la formation Gestion des secrets.
Pourquoi Keycloak paraît-il si difficile ?
Section intitulée « Pourquoi Keycloak paraît-il si difficile ? »Parce qu'il expose toute sa puissance dès la première page de sa console. Un
débutant qui s'y connecte voit des realms, des clients, des scopes, des
mappers, des flows d'authentification et des policies, sans savoir lequel de
ces objets le concerne. Il clique partout, puis bute sur une erreur comme
Invalid parameter: redirect_uri sans voir qu'il a raté un concept, pas
une case à cocher.
L'ordre de la formation part du principe inverse : on comprend le protocole avant de configurer l'outil. Keycloak n'est qu'une implémentation d'OAuth 2.0 et d'OpenID Connect ; qui ne sait pas ce qu'est un authorization code flow ne peut pas déboguer un client OIDC, quel que soit le nombre de tutoriels suivis. Le vocabulaire et les bases viennent donc en premier, puis un premier fournisseur d'identité tourne vite, et chaque flux est observé avant d'être détaillé.
Comment la formation est-elle organisée ?
Section intitulée « Comment la formation est-elle organisée ? »La formation suit deux niveaux : brancher une application sur un fournisseur d'identité, puis l'exploiter et gouverner les accès. Keycloak est l'outil de référence sur tout le parcours. Le programme détaillé, avec votre progression leçon par leçon, est sur la page Mon parcours ; cette section en donne le fil, et la page de parcours fait foi pour les intitulés et les durées.
Niveau 1 : brancher une application sur un fournisseur d'identité
Section intitulée « Niveau 1 : brancher une application sur un fournisseur d'identité »Le premier niveau mène d'un vocabulaire à une application connectée. Il commence par le module Comprendre l'IAM, qui pose les bases de l'IAM (identités, authentification, autorisation), les modèles d'autorisation avec leurs limites, et la cryptographie des jetons (signature, JWKS, certificats).
Le module Premier fournisseur d'identité met Keycloak en main, avec PostgreSQL comme base : concepts et architecture, puis l'installation avec Docker sur PostgreSQL, enfin l'administration des realms, utilisateurs, groupes et rôles. Le module OAuth 2 et OpenID Connect explique la délégation d'accès avec OAuth 2, l'authentification avec OpenID Connect et la vie des jetons et des sessions, puis les applique : sécuriser une application, observer le cycle de vie des jetons et protéger une API par audience et scopes.
Le module Fédération et annuaires relie le fournisseur d'identité à l'existant. Il compare SAML 2.0 à OIDC, présente les annuaires d'entreprise (LDAP, Active Directory, Kerberos), monte un annuaire léger avec LLDAP, le fédère dans Keycloak, puis délègue la connexion à un fournisseur d'identité partenaire. Il se termine par la méthode pour dépanner une intégration OIDC ou SAML. Le niveau se conclut par une épreuve sans commande sous les yeux : brancher une application et une API sur Keycloak, notée sur des preuves observables.
Niveau 2 : exploiter et gouverner
Section intitulée « Niveau 2 : exploiter et gouverner »Le second niveau suppose un fournisseur d'identité en marche et s'intéresse à ce qui le rend sûr dans la durée. Le module Authentification forte traite MFA, WebAuthn et passkeys, ce qui résiste au phishing et ce qu'en exige NIST SP 800-63B-4, puis impose un second facteur au seul groupe sensible dans Keycloak. Le module Cycle de vie et gouvernance automatise l'arrivée, la mobilité et le départ des comptes avec le provisioning SCIM, puis les fait appliquer par Keycloak et conduit la revue des accès.
Le module Brancher la plateforme porte l'identité des workloads, avec la leçon partagée Identité machine et workload identity, qui garde son plan de cours dans la formation Gestion des secrets, puis branche Kubernetes et Vault sur le realm par les groupes. Le module Sécuriser et exploiter couvre les menaces, le durcissement, la surveillance et la réponse à incident dans la sécurité opérationnelle IAM, puis Keycloak en production (proxy TLS, sauvegarde, montée de version, compte de secours), Keycloak sur Kubernetes avec l'Operator et la configuration du realm en code. Une seconde épreuve, exploiter et gouverner un fournisseur d'identité, termine la formation.
authentik, en option
Section intitulée « authentik, en option »Le module authentik (facultatif) est une découverte, pas une alternative à suivre en parallèle. authentik est un second fournisseur d'identité. Il présente les objets d'authentik avec applications, providers, flows et outposts, puis l'installation avec Docker Compose. Il sert à comparer une seconde approche une fois Keycloak maîtrisé ; rien dans le reste de la formation n'en dépend.
Ce que la formation ne couvre pas
Section intitulée « Ce que la formation ne couvre pas »L'honnêteté sur les limites vaut mieux qu'une promesse creuse. Plusieurs sujets voisins ont leur propre guide ou sortent du périmètre.
- Les accès privilégiés (PAM) : Teleport et les certificats SSH de Vault vivent dans la sécurité des accès et la formation Gestion des secrets. Ne les confondez pas avec les modules PAM de Linux.
- L'IAM des fournisseurs cloud : le guide IAM cloud traite les rôles, politiques et recertification côté cloud.
- Les extensions Java de Keycloak (SPI, providers personnalisés) : c'est un métier en soi.
- Les Authorization Services de Keycloak (UMA, policies fines) : puissants mais rarement utilisés, souvent remplacés par une autorisation portée par l'application.
- Les applications sans OIDC derrière un proxy d'authentification : le cadrage prévoyait d'en brancher une, la formation ne le traite pas. Le principe est seulement évoqué dans la leçon sur la plateforme, et chaque proxy a son guide : authentification et ForwardAuth avec Traefik, Pomerium et Dex.
- La haute disponibilité poussée (réglage Infinispan, multi-sites) dépasse le cadre d'une formation généraliste.
Pour situer l'identité dans une architecture de services, la page Identité et autorisation de la formation Architecture des services en donne la vue d'ensemble.
Quels sont les trois piliers de l'IAM ?
Section intitulée « Quels sont les trois piliers de l'IAM ? »L'IAM repose sur trois étapes successives : identification, authentification, autorisation. L'identification est la déclaration de qui l'on est, via un identifiant unique (nom d'utilisateur, email, badge), sans aucune preuve. Sans elle, impossible de personnaliser les accès ni de tracer les actions de chacun.
L'authentification vérifie que la déclaration est vraie, grâce à un ou plusieurs facteurs :
| Facteur | Ce que c'est | Exemple |
|---|---|---|
| Ce que vous savez | Connaissance secrète | Mot de passe, code PIN |
| Ce que vous possédez | Objet physique ou secret détenu | Clé FIDO2, application TOTP |
| Ce que vous êtes | Biométrie | Empreinte digitale, visage |
L'authentification multi-facteurs (MFA) combine plusieurs de ces facteurs, par exemple un mot de passe et un code à usage unique d'une application (TOTP). Une clé FIDO2 ou une passkey résiste en plus au phishing, ce que le SMS ne fait pas : exposé au détournement de carte SIM, c'est le facteur le plus faible.
L'autorisation détermine enfin ce que l'utilisateur authentifié peut voir et faire, selon le moindre privilège. Le RBAC attribue les permissions par rôle (admin, éditeur, lecteur), l'ABAC par attributs (département, localisation, heure). Un développeur accède ainsi au dépôt Git mais pas aux logs de production ; un SRE a accès aux deux. La leçon RBAC, ABAC et politiques d'autorisation détaille les modèles.
Comment l'IAM a-t-il évolué ?
Section intitulée « Comment l'IAM a-t-il évolué ? »Les outils d'aujourd'hui s'empilent sur trois décennies. L'annuaire LDAP et le RBAC des années 1990 sont toujours là, sous le SSO et le MFA des années suivantes. Le tableau situe chaque brique dans le temps, ce qui explique pourquoi une infrastructure réelle combine presque toujours plusieurs générations.
| Période | Avancée majeure |
|---|---|
| Années 1990 | LDAP centralise les identités, RBAC structure les permissions |
| Années 2000 | SSO et fédération (SAML) se répandent en entreprise ; le MFA s'y généralise ensuite pour les accès sensibles |
| Années 2010 | OAuth 2 et OpenID Connect portent le SSO vers le web et les API |
| Aujourd'hui | Passkeys, Zero Trust, audit continu |
Quelle brique choisir pour quel besoin ?
Section intitulée « Quelle brique choisir pour quel besoin ? »L'IAM n'est pas un produit mais une chaîne : l'annuaire (source d'identité), l'IdP/SSO, le provisioning, le moteur d'autorisation, puis l'application des décisions (proxy, passerelle d'API, application). La formation s'arrête à Keycloak, authentik, LLDAP et au provisioning SCIM ; le tableau situe aussi les outils voisins, que vous croiserez en entreprise.
| Besoin principal | Famille d'outil | Exemples |
|---|---|---|
| SSO OIDC/SAML à l'échelle | IdP complet | Keycloak, authentik, ZITADEL |
| Protéger des applications web derrière un reverse proxy | Portail SSO | Authelia, LemonLDAP::NG, Pomerium |
| Annuaire minimal (lab, petite infra) | LDAP léger | LLDAP |
| Annuaire d'entreprise, réplication | LDAP | OpenLDAP, 389 Directory Server |
| Fédérations académiques, SAML pur | IdP/SP SAML | Shibboleth, SimpleSAMLphp |
| Droits applicatifs complexes (partage, multi-tenant) | Autorisation fine (ReBAC, Zanzibar) | OpenFGA, SpiceDB, Ory Keto |
| Sortir l'autorisation du code | Moteur de politiques | OPA, Cerbos |
| CIAM « composable » (construire son produit) | Briques headless | Ory Kratos et Hydra |
Lisez la première colonne avant les noms d'outils : un portail SSO devant un reverse proxy et un IdP complet ne répondent pas au même problème, même s'ils parlent tous deux OIDC. Une application qui ne parle que SAML écarte d'emblée les outils limités à OIDC.
À retenir
Section intitulée « À retenir »- Identification ≠ authentification : déclarer son identité n'est pas la prouver.
- Le MFA bloque la grande majorité des attaques par vol d'identifiants ; le SMS est son facteur le plus faible, une clé FIDO2 ou une passkey résiste au phishing.
- L'autorisation suit le moindre privilège : n'accorder que les droits strictement nécessaires.
- L'IAM est une chaîne : annuaire, IdP/SSO, provisioning, moteur d'autorisation, application des décisions.
- La formation compte deux niveaux : brancher une application sur un IdP, puis exploiter et gouverner les accès, avec Keycloak en référence.
- authentik est un module facultatif de découverte ; les accès privilégiés et l'IAM cloud ont leurs propres guides.