Ce que c’est
Solution de gestion des identités et des accès : authentification unique, fédération, autorisations.
Ce qu’on y travaille dans le laboratoire
- ·Authentifier clients, agents, marchands et opérateurs
- ·Porter l’institution dans le jeton d’accès
- ·Travailler l’authentification forte
Parcours de maîtrise
Quatre niveaux, 200 heures, 40 travaux pratiques — de la découverte à l’architecture.
Niveau 1 · 20 h · TP 1 à 10
Keycloak Operator
Comprendre les fondamentaux de la gestion des identités et administrer un environnement de laboratoire.
- Authentification et autorisation : les notions et leur vocabulaire
- Installation, base de données, premier démarrage
- Domaine de sécurité, utilisateurs, groupes, rôles, clients
- Notions OpenID Connect, sessions, politiques de mot de passe
Niveau 2 · 40 h · TP 11 à 20
Application Security Engineer
Sécuriser des applications et des interfaces de programmation.
- OAuth 2.x, code d’autorisation, PKCE, identifiants de service
- Jetons JWT, clés publiques, audiences, expiration
- Portées d’accès, contrôle par rôles, passerelle d’API
- Authentification multifacteur et clés d’authentification physiques
Niveau 3 · 60 h · TP 21 à 30
Payment Security Engineer
Appliquer la gestion des identités à une infrastructure de paiement.
- Sécurisation d’une API de paiement : portées, rôles, institution appelante
- Identités de machines et comptes de service pour les connecteurs
- Fédération d’identités, cloisonnement par institution
- Autorisation fine, principe du double regard, chiffrement mutuel
- Authentification renforcée sur les opérations sensibles
Niveau 4 · 80 h · TP 31 à 40
IAM Architect
Concevoir et exploiter une plateforme d’identités de niveau production.
- Haute disponibilité, orchestration de conteneurs, gestion des certificats
- Identités décrites comme du code, versionnées et rejouables
- Intégration d’un gestionnaire de secrets
- Observabilité, centralisation des événements de sécurité, durcissement
- Réponse à incident et exercices offensifs et défensifs
Le parcours se valide sur preuve. Chaque niveau se franchit par une démonstration en conditions réelles devant un jury, avec un critère d’acceptation écrit à l’avance — la règle de la Méthode SAKITI appliquée au laboratoire.
L’écosystème à sécuriser
Le laboratoire simule les identités de sept catégories d’acteurs, humains et machines.
- 01Banques : employés, administrateurs, opérateurs, clients
- 02Fintechs : applications, développeurs, services
- 03Marchands : utilisateurs et applications d’encaissement
- 04Régulateurs et auditeurs : accès de consultation et de contrôle
- 05Partenaires : dispositifs de paiement et plateformes d’interopérabilité
- 06Administrateurs du laboratoire : exploitation et support
- 07Machines : interfaces, microservices, connecteurs et moteurs
Standards et protocoles à maîtriser
Dix domaines, et pour chacun ce qu’il faut savoir manipuler.
| Domaine | Ce qu’il faut savoir manipuler |
|---|---|
| Authentification | OpenID Connect, authentification unique, multifacteur, clés physiques |
| Autorisation | OAuth 2.x, contrôle par rôles, par attributs, portées d’accès |
| Fédération | Fournisseur d’identité externe, SAML 2.0, annuaire d’entreprise |
| Jetons | JWT, jeux de clés publiques, revendications, audiences |
| Machine à machine | Identifiants de service, comptes techniques |
| Sécurité du transport | TLS, chiffrement mutuel |
| Approvisionnement | SCIM et mécanismes de synchronisation |
| Sécurité des interfaces | Passerelle, validation des jetons, portées, limitation de débit |
| Audit | Événements, journaux, traces, centralisation |
| Secrets | Gestionnaire de secrets, secrets d’orchestration |
Les quarante travaux pratiques
Quatre blocs de dix, du premier démarrage à l’exercice offensif.
TP 1 à 10 — Fondations
- Installer le serveur
- Connecter la base de données
- Créer le domaine de sécurité
- Créer les utilisateurs
- Créer groupes et rôles
- Créer un client OpenID Connect
- Tester connexion et déconnexion
- Explorer les sessions
- Configurer une politique de mot de passe
- Explorer les points d’accès du protocole
TP 11 à 20 — Applications et interfaces
- Code d’autorisation
- PKCE
- Identifiants de service
- Décoder et vérifier un jeton
- Sécuriser un service applicatif
- Intégrer une passerelle d’API
- Mettre en œuvre des portées d’accès
- Contrôle par rôles
- Double regard
- Authentification multifacteur
TP 21 à 30 — Paiements et intégrations
- Sécuriser une API de paiement
- Comptes de service
- Identité de machine
- Fédération d’identités
- Cloisonnement par institution
- Autorisation fine
- Chiffrement mutuel
- Sécuriser le connecteur de paiement instantané
- Sécuriser la plateforme d’intégration
- Sécuriser la couche de services
TP 31 à 40 — Production et sécurité
- Déployer sur une orchestration de conteneurs
- Configurer la haute disponibilité
- Gérer les certificats
- Décrire les identités comme du code
- Intégrer le gestionnaire de secrets
- Mettre en place l’observabilité
- Centraliser les événements de sécurité
- Durcir la configuration
- Exercice offensif et défensif
- Architecture finale
Ce que traverse une requête de paiement
Sécuriser un point d’entrée, ce n’est pas cocher une case : c’est empiler des contrôles qui tombent tous du même côté.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | www.keycloak.org |
| Dépôt public | github.com/keycloak/keycloak |
À vérifier au moment de la qualification. Licence exacte, version courante, activité du projet, gestion des vulnérabilités et conditions de support évoluent. Le statut affiché sur ce radar ne vaut ni certification, ni aptitude au déploiement en production dans une infrastructure de paiement.