Fédération d’identité – Keycloak

Les systèmes d’information deviennent de plus en plus complexes à chaque évolution de ce dernier. Pour chacune d’elle, de nouveaux modules sont intégrés pour répondre à un besoin métier, client ou technique. Cette nouvelle physionomie modulaire de nos SI doit répondre à une problématique bien connue, la sécurité.

Nous ne parlons pas ici de la sécurité en terme de cybermenace ou d’attaque extérieure, ayant pour but d’anéantir notre système ou de récupérer nos données sensibles. Il s’agit de la sécurité liée aux accès de chaque module du SI. Qui sont nos utilisateurs ? Qui peut se connecter à telle ou telle application ? Qui est connecté ?

Un constat semble émerger, un constat dont chacun peut se rendre compte dans sa vie de tous les jours en utilisant nos SI modernes. Chaque module dispose souvent de son propre système d’accès, nous contraignant à nous connecter à chaque fois, à chaque application de notre SI, avec toujours les mêmes identifiants.

Au-delà de l’aspect répétitif de ces actions, grain de sable pourtant suffisamment gênant dans les rouages de notre quotidien, n’aurions-nous pas déjà une solution pour nous permettre de sécuriser l’accès à l’ensemble de nos applications de manière centralisée ? Bonne nouvelle, nous l’avons, il s’agit des IAM.

« Identity and Access Management », la solution de centralisation

N’en déplaise aux plus mélomanes des lecteurs de cet article, les solutions IAM (« Gestion des Identités et des Accès » en français) sont l’exacte solution à la problématique relevée.  Elles permettent de gérer l’identification, l’authentification ainsi que les autorisations de l’ensemble des utilisateurs d’un SI de façon centralisée.

Cette solution sera une nouvelle brique à ajouter à notre système. Encore une ? Oui, mais celle-ci s’y intègre pour le plus grand bien. Pour, dans un premier temps, grossièrement décrire son fonctionnement, les différents modules déjà existants du SI vont totalement déléguer la phase d’authentification des utilisateurs à l’IAM. Celui-ci va donc devenir le cœur battant de cette première étape du cycle de vie de nos applications en servant de relai ou de substitut aux mécanismes préexistants (LDAP, Base de données utilisateurs, etc…).

Les principaux enjeux pour la mise en œuvre d’un IAM au sein d’un système d’information sont les aspects :

  • Sécurité : nous remplaçons une multitude de points d’entrées, qui sont autant de failles possibles dans notre SI, par un unique point d’entrée qui gèrera les droits d’accès aux applications
  • Financier : avec une unique solution à maintenir pour l’ensemble de notre SI
  • Souplesse : une interface unique d’authentification pour l’ensemble des applications

Keycloak, la solution IAM en vogue

Afin de répondre un peu plus en détail sur les questions que vous vous posez certainement sur les mécanismes de fonctionnement des IAM, nous allons nous intéresser plus spécifiquement à la solution Keycloak. Cette dernière est très certainement une des solutions les plus intégrées pour répondre au problème de centralisation des identités et des accès. Il existe des solutions concurrentes, mais qui reposent sur les mêmes principes de fonctionnement, nous n’irons donc pas nous perdre dans un comparatif.

Pour un petit aparté biographique et juridique, la solution Keycloak a été lancée le 10 septembre 2014, sous licence Apache License 2.0, et est portée par la communauté JBoss sous la responsabilité de Red Hat.

A noter que du point de vue de l’intégration, étant une solution Open Source, il est tout à fait possible de l’installer et la configurer sans frais d’achat de licence. Red Hat ne fournira cependant aucun support technique (même payant) pour Keycloak. Comme pour bon nombre de ses produits, Keycloak est un projet Open Source avec une notion de « Top features », qui seront, une fois validées et pérennisées, disponibles dans le produit « RH-SSO » qui lui n’est pas Open Source mais qui permet cependant de bénéficier d’un support payant. L’équivalence des fonctionnalités entre RH-SSO et Keycloak est disponible très clairement sur le site de ce dernier afin de valider la solution la plus adaptée à notre contexte.

L’authentification via l’IAM

Comme précisé précédemment, les applications de notre système d’information vont déléguer leur phase d’authentification à Keycloak. Un bon schéma valant mille mots, voici le chronogramme de cette étape :

Une fois l’utilisateur authentifié (phase présentée ci-après) dans l’interface de Keycloak, il sera redirigé vers l’application cible. Et à l’aide d’un jeton d’authentification, l’application aura connaissance de l’identité de l’utilisateur, et s’il possède ou non tel ou tel accès.

Pour pouvoir connecter nos applications existantes à Keycloak, il va être nécessaire d’y rajouter un « Client Adapter » ou un plugin afin de paramétrer les informations relatives à notre instance d’IAM. Selon les langages utilisés, Keycloak fournit dans sa documentation les informations pour créer et gérer son module de connexion. Fort de son succès croissant, certaines applications fournissent déjà leur propre plugin de connexion à Keycloak par défaut (comme dans l’outil Jenkins par exemple). De plus, les protocoles d’authentification disponibles sont l’OpenID Connect, SAML et OAuth 2.0. Ces noms ne vous disent peut-être pas grand-chose mais sachez tout simplement que ce sont des protocoles standardisés et les plus utilisés. Nous n’irons pas dans le détail de ces protocoles dans cet article, mais sachez que la plupart des concurrents à Keycloak utilisent les mêmes protocoles (notamment OpenID Connect), ce qui va permettre de réduire les coûts en cas de changement de solution. Une simple modification de valeurs des clés de configuration OpenID Connect vous permet de basculer de votre instance Keycloak vers une autre solution (et vice-versa).

Fédération d’identités dans l’IAM

Nous l’avons plus haut dans cet article, l’un des atouts majeurs pour la mise en place d’un IAM comme Keycloak au sein de son système d’information est de promouvoir un unique point d’entrée d’authentification. Il faut donc qu’il soit en mesure d’agréger les différentes sources qui étaient jusque-là utilisées pour permettre la connexion à nos applications.

Pour cela, Keycloak va avoir besoin de se connecter à plusieurs sources externes de données et de lier les informations à chaque utilisateur. Nativemment, Keycloak fournit la possibilité d’utiliser les protocoles LDAP et Kerberos pour la fédération d’identité ainsi que la possibilité de se connecter à une multitude de source grâce à des « Identity Providers ». Ces derniers reposent sur SAML 2.0, OpenID Connect ou bien ce que l’on appelle du « Social Login » pour la connexion aux différents réseaux sociaux disponibles (Google, Gitlab, Twitter, etc.).

Pour prendre exemple sur un cas pratique relativement simple, nous allons imaginer que notre système d’information possède un LDAP interne qui permet historiquement de se connecter à nos différentes applications. Nous ajoutons à cela une plateforme de connexion externe, par exemple avec une offre Office 365. Nous allons pouvoir enregistrer ce nouvel Identity Provider. Cette nouvelle source possible d’identification sera rajoutée comme option de connexion sur la page unifiée d’authentification.

A l’aide de « mappers », nous allons pouvoir définir les attributs provenant de chaque source (interne et externe) afin de lier les comptes à un même utilisateur. Dans cet exemple, nous créerons les règles nécessaires à la récupération des noms, prénoms et adresses mails de nos utilisateurs pour les deux sources d’identification afin de les lier à un compte unique.

Au-delà de l’aspect pratique pour l’utilisateur et d’ajouter de la souplesse d’utilisation à notre SI, il s’agit également (et principalement) de s’assurer de la cohérence des droits d’accès à nos applications pour chaque utilisateur (ou groupe d’utilisateurs). En liant les sources et les comptes à des identités uniques, il est plus simple et moins coûteux de gérer leurs autorisations.

En résumé

Devant la montée en complexité de nos SI, dont le nombre d’applications qui les composent explosent, les solutions IAM (Keycloak ou autre) offrent une réelle opportunité de centralisation et de sécurisation à mettre en place. Chacune de ces solutions offrent ses propres particularités, je vous invite donc à regarder de plus Okta (solution propriétaire très complète) ou bien Gluu (projet regroupant des solutions open source), qui sont les concurrentes de Keycloak.

Pour conclure cet article sur les solutions de gestion des identités et des accès et sur les possibilités qu’offrent Keycloak, nous pourrions nous satisfaire de l’adaptation d’une citation bien connue « One (IAM) to rule them all ».

Leave a Reply

Your email address will not be published. Required fields are marked *