Keycloak s’impose aujourd’hui comme une solution open source robuste pour répondre à ces besoins.
Sa capacité à s’intégrer avec des annuaires existants, à déléguer l’authentification à des fournisseurs externes et à être étendu via des mécanismes de personnalisation en fait un outil particulièrement adapté aux contextes d’entreprise.
Provisioning
Keycloak est équipé en standard pour gérer de A à Z ses utilisateurs. La console d'administration est présente et permet aux administrateurs d'ajouter, modifier et supprimer les comptes. Il est également possible de piloter cette gestion via l'API d'administration.
Cependant, dans le contexte d'une organisation souhaitant utiliser Keycloak comme outil interne d'authentification, il existe souvent une source d'utilisateurs déjà présente. Cette "source" correspond la plupart du temps à un annuaire, que ce soit Active Directory, OpenLDAP ou tout annuaire prenant en charge le protocole LDAP. Dans ce cas, Keycloak peut utiliser cet annuaire comme source, on parle alors de fédération d'utilisateurs. La gestion des utilisateurs se fait uniquement dans l'annuaire avec les outils déjà en place, et Keycloak devient un simple consommateur de cet annuaire.
Dans certains cas, la source d'utilisateurs n'est pas un annuaire LDAP. L'intégration passe alors par le développement Java d'un User Storage SPI. Il devient alors possible de connecter Keycloak à un peu tout ce qui existe : base de données, API Web, SCIM etc.
En parlant de SCIM, ce protocole va bientôt être disponible directement dans Keycloak sans avoir à passer par une extension ou un développement. Une première implémentation permettra d'utiliser Keycloak en tant que fournisseur SCIM : les applications clientes pourront utiliser Keycloak pour provisionner leurs comptes. Puis dans un second temps, Keycloak sera capable d'être lui-même client d'un fournisseur SCIM (tel que Microsoft Entra ID) permettant ainsi de se rapprocher du principe de provisioning via un annuaire LDAP.
Derniers points concernant le provisionning : les workflows. L'usage de workflows est une nouvelle fonctionnalité de Keycloak présente depuis la version 26.5.0. Toujours en "preview", elle permet d'organiser et d'orchestrer les tâches administratives liées à la gestion des identités et des accès.
Délégation et gestion des organisations
De nos jours, un SI est rarement isolé sur un réseau interne : les comptes utilisateurs sont présents chez un fournisseur d'identité tel que Microsoft Entra ID ou Google Workspace, ou les applications internes doivent être accessibles à des partenaires ou clients.
C'est dans ce genre de contexte que Keycloak permet de simplifier la gestion de l'authentification tout en conservant un haut niveau de sécurité. En tant que fournisseur d'identité pour les applications du SI, Keycloak peut lui-même déléguer l'authentification à des fournisseurs externes et permettre ainsi un usage transparent de ces fournisseurs d'identité pour les applications clientes de Keycloak.
Il devient ainsi possible d'ouvrir des applications internes à des partenaires en leur autorisant à utiliser leur propre système d'authentification. Pas de nouveau compte à créer. Pas de nouveau mot de passe à retenir. Simplification du processus d'authentification.
Côté Keycloak, cette fonctionnalité est portée par la gestion des organisations. Une organisation correspond à une entité regroupant des utilisateurs liés par un domaine d'adresse email identique. Il est ainsi possible dans Keycloak d'indiquer que tous les utilisateurs dont l'adresse email finit par @example.com devront s'authentifier auprès de auth.example.com (ou pour @example.org via sso.example.org, etc.).
Dans un registre similaire, mais légèrement différent, Keycloak peut également simplifier l’intégration de ProConnect dans un extranet à destination des professionnels de la fonction publique. L’extranet, ou n’importe quel service exposé sur Internet, délègue l’authentification à Keycloak, qui lui-même, propose la possibilité de s’authentifier via ProConnect, en plus de la connexion classique pour les utilisateurs de l’entreprise.
Sécurité renforcée
Pour un usage interne ou privé de Keycloak, la population cible est connue et maîtrisée. Il est ainsi possible d'appliquer des règles de sécurité renforcées qu'il serait compliqué d'appliquer pour un usage de Keycloak ouvert au public.
On pensera tout de suite aux politiques d'authentification avec notamment la qualité du mot de passe, puis juste après la mise en place d'un second facteur d'authentification.
Ces fonctionnalités sont présentes en standard dans Keycloak permettant ainsi de forcer l'usage d'un second facteur d'authentification basé sur un code TOTP ou sur WebAuthn en fonction des moyens mis à disposition des utilisateurs (smartphone, token physique, etc.).
Cette sécurité renforcée bénéficie à toutes les applications clientes déléguant l'authentification à Keycloak, permettant ainsi d'élever le niveau de sécurité globale de l'ensemble d'un SI.
Développements et personnalisations
Pour les cas où les fonctionnalités proposées par Keycloak ne couvriraient pas l’ensemble des besoins, il reste toujours la possibilité de passer par la case développements personnalisés.
La philosophie derrière Keycloak étant basée sur l'ouverture, il n'est pas surprenant que celui-ci facilite (et encourage) les personnalisations et adaptations pour coller au plus proche des différents besoins rencontrés dans la vie d’une entreprise.
Via l'usage de Service Provider Interface (SPI), il est possible d'étendre les fonctionnalités de Keycloak en ajoutant de nouvelles implémentations qui modifient, remplacent ou étendent les fonctionnalités de Keycloak.
On en a parlé rapidement au-dessus (dans la partie "Provisioning") avec la possibilité d'utiliser une base de données externe comme source des utilisateurs de Keycloak via le développement d'un “User Storage SPI”. À noter que sur le même principe, l'usage d'un annuaire LDAP par Keycloak est lui-même un “User Storage SPI”, mais inclut par défaut avec Keycloak.
Il devient ainsi possible d'ajouter à Keycloak les règles, fonctionnalités ou développements qui sont spécifiques à un usage. La liste des SPI disponibles est relativement longue, on ne les listera pas tous ici. Il est cependant possible d'obtenir cette liste dans la console d'administration de Keycloak, au niveau du realm "master" dans l'onglet "Provider info".
Pour donner quelques exemples, on pourra noter :
- l'utilisation de nouveaux systèmes de stockage pour les utilisateurs (le fameux User Storage SPI)
- l'ajout d'un algorithme de hachage de mots de passe, permettant de réutiliser les mots de passe existant lors d'une reprise depuis un ancien système d'authentification
- l'ajout de nouveaux mécanismes d'authentification ou de steps à ajouter dans les flows d'authentification (Authentication SPI)
- réagir à des événements avec le Event Listener SPI
- etc.
Le développement de ces SPI se fait en Java. Keycloak ne pose aucune contrainte sur le développement ni sur l'exécution de ces SPI.
Que ce soit pour sécuriser des applications internes, ouvrir des services à des partenaires ou unifier les mécanismes d’authentification d’un SI, Keycloak constitue une brique stratégique souple et sécurisée.