À l’époque où ma génération était jeune, sauvage et libre (je rigole), chaque fois que nous développions une application web, la première chose à laquelle nous devions penser était l’authentification.
Chaque fois, c’était une sorte de casse-tête : prévenir les injections SQL et autres types d’attaques, stocker les profils utilisateurs et les mots de passe chiffrés, choisir quel cookie d’authentification utiliser, et ainsi de suite.
Il y avait très souvent quelque chose qui nous faisait nous gratter la tête. La charge de travail augmentait encore lorsque notre application devait prendre en charge des identités externes d’utilisateurs provenant, par exemple, de Twitter, Facebook ou Google.
L’avènement de ces fournisseurs d’identité externes et globaux utilisant des protocoles d’authentification et d’autorisation basés sur OpenID (comme OAuth) nous a permis de faire un énorme bond en avant : il n’était plus nécessaire que notre application stocke les mots de passe des utilisateurs, pour ne citer qu’un des avantages.
Les choses se sont encore améliorées avec l’arrivée de plateformes logicielles de fournisseurs d’identité comme Keycloak. Nous avons alors découvert qu’il était possible de déployer notre propre fournisseur d’identité directement dans notre infrastructure (soit sur site, soit dans le cloud), nous offrant ainsi un contrôle total sur les politiques d’authentification et d’autorisation, le stockage des profils utilisateurs, et la fédération d’authentification, le tout en un seul endroit et conforme aux normes de sécurité les plus élevées.
De plus, intégrer l’authentification et l’autorisation de Keycloak avec nos applications nécessite très peu d’effort : il suffit d’importer un connecteur dédié (appelé adapter) dans notre application, pour que toute la communication et l’échange de jetons liés à l’authentification soient déjà pris en charge pour nous.
Keycloak fournit des fonctionnalités telles que la fédération d’utilisateurs, l’authentification renforcée, la gestion des utilisateurs, l’autorisation granulaire, et bien plus encore. Ses fonctionnalités incluent :
- Single sign-on et single sign-out
- Thèmes de connexion personnalisables
- Intermédiation d’identité et connexion via réseaux sociaux
- Fédération d’utilisateurs
- Console d’administration
- Console de gestion des comptes
- Protocoles standard
- Services d’autorisation
Dans cet article, nous présenterons ce que Keycloak peut faire et pourquoi il peut être considéré comme le couteau suisse répondant à presque tous les besoins en gestion des identités.
Keycloak en tant que gestionnaire d'identités
L’une des différences les plus importantes à comprendre lors de l’adoption de Keycloak est que vos utilisateurs ne s’authentifieront plus directement auprès de vos applications, mais auprès de Keycloak.
Cela signifie qu’en tant que développeur, vous n’aurez plus à gérer les formulaires de connexion, l’authentification des utilisateurs et le stockage des utilisateurs dans vos applications.
Une fois connectés à Keycloak, les utilisateurs n’ont plus besoin de se reconnecter pour accéder à vos différentes applications ; c’est ce qu’on appelle le single sign-on.
Il en va de même pour la déconnexion : Keycloak offre le single sign-out, ce qui signifie que les utilisateurs n’ont besoin de se déconnecter qu’une seule fois pour être immédiatement déconnectés de toutes les applications.
Commencer avec Keycloak
Il existe plusieurs options pour obtenir Keycloak, toutes disponibles ici : https://www.keycloak.org/downloads.
Bien que l’installation et la configuration de Keycloak nécessiteraient un article à part entière, nous pouvons dire qu’un bon équilibre entre déploiement rapide et flexibilité peut probablement être atteint en installant Keycloak à l’aide d’une image de conteneur (compatible avec Docker, Podman, OpenShift et Kubernetes).
Keycloak prend en charge de nombreux systèmes de bases de données existants (basés sur JPA), parmi lesquels on trouve nos préférés : H2, MySQL, PostgreSQL, MariaDB, Oracle ou Microsoft SQL Server.
Si vous pensez à la haute disponibilité ou même à un déploiement en cluster, nous aborderons ces sujets un peu plus loin dans cet article.
Tout tourne autour des realms
Options Générales
L’onglet Général dans chaque realm présente les paramètres de base, tels que son nom affiché (en texte brut ou en HTML, utile pour les formulaires de connexion du realm) et son statut (activé ou désactivé).
Cependant, trois paramètres supplémentaires peuvent être particulièrement intéressants :
Frontend URL : permet de spécifier une URL dédiée au realm, pour remplacer l’URL de base pour les requêtes frontend. Par exemple, si votre installation Keycloak est accessible à
https://idp.mycompany.com, l’URL frontend pourrait êtrehttps://myrealm.idp.mykeycloak.org.User-Managed-Access : active ou désactive la capacité des utilisateurs du realm à accéder à leur Console de Gestion de Compte. C’est l’endroit où ils peuvent vérifier leurs activités, terminer les sessions ouvertes et changer leur mot de passe.
Endpoints : expose les métadonnées du fournisseur d’identité de Keycloak sous deux formats : OpenID et SAML 2.0. Ce sont les endpoints que vous, en tant qu’administrateur de la gestion des identités, transmettrez aux fournisseurs d’identité externes lors de la configuration de l’authentification fédérée.
Options de Login
Les options de login offrent également des choix intéressants :
- Activer ou désactiver la page d’inscription, ainsi qu’un lien vers l’inscription sur la page de login.
- Afficher/masquer le champ du nom d’utilisateur sur le formulaire d’inscription ; s’il est masqué, le champ e-mail est utilisé comme nom d’utilisateur pour les nouveaux utilisateurs.
- Rendre le champ du nom d’utilisateur modifiable.
- Activer/désactiver le lien sur la page de login pour lancer la procédure de réinitialisation du mot de passe.
- Afficher/masquer la case à cocher sur la page de login permettant aux utilisateurs de rester connectés entre les redémarrages du navigateur jusqu’à l’expiration de la session.
- Exiger des utilisateurs qu’ils vérifient leur adresse e-mail après leur première connexion ou après toute modification de celle-ci.
- Permettre aux utilisateurs de se connecter avec leur adresse e-mail.
- Autoriser deux utilisateurs différents à utiliser la même adresse e-mail.
- Déterminer si HTTPS est requis :
- ‘None’ : HTTPS n’est pas requis pour les adresses IP des clients.
- ‘External requests’ : localhost et les adresses IP privées peuvent accéder sans HTTPS.
- ‘All requests’ : HTTPS est requis pour toutes les adresses IP.
Options de Email
Options de Défenses de Sécurité
Thèmes de Login
Comme mentionné précédemment, un utilisateur peut se connecter uniquement au realm auquel il appartient.
Cependant, chaque realm peut personnaliser son propre formulaire de login, ce qui permet à différents realms d’utiliser des modèles distincts sur le même serveur ou cluster.
Keycloak est livré avec des thèmes par défaut, mais il est possible d’ajouter des thèmes personnalisés créés par les utilisateurs.
Voici ci-dessous le formulaire de login standard de Keycloak :
Le thème à utiliser est lié au realm, ce qui permet à différents realms d’utiliser des modèles distincts sur le même serveur ou cluster.
Intermédiation d'Identité et Connexion via Réseaux Sociaux
Grâce à l’adoption de protocoles d’authentification standard, Keycloak est capable d’agir comme intermédiaire d’identité pour pratiquement n’importe quel fournisseur d’identité externe utilisant OpenID ou SAML 2.0.
D’ailleurs, il offre une prise en charge native pour :
- Github
- Microsoft
- BitBucket
- Openshift v4
- Openshift v3
- Gitlab
- PayPal
- StackOverflow
Oh, et n’oublions pas dans cette liste (évidemment) Keycloak OpenID Connect, ce qui simplifie grandement les choses lorsque vous devez fédérer avec un autre fournisseur d’identité externe basé sur Keycloak.
Pour permettre à vos applications de laisser les utilisateurs s’authentifier via Keycloak, vous pouvez utiliser l’un des nombreux adapters directement fournis :
- Java (JBoss EAP, WildFly, Tomcat, Jetty 9, Servlet Filter, Spring Boot, Spring Security)
- JavaScript (côté client)
- JavaScript Node.js (côté serveur)
- C# OWIN (communauté)
- Python (oidc generic)
- Android (AppAuth generic)
- iOS (AppAuth generic)
- Apache HTTP Server (mod_auth_openidc)
Pour permettre à vos applications de laisser les utilisateurs s’authentifier via Keycloak, vous pouvez utiliser l’un des nombreux adapters directement fournis :
Flux d'Intermédiation d'Identité
Fédération d'Utilisateurs
Keycloak stocke et gère les utilisateurs. Cependant, les entreprises disposent souvent de services LDAP ou Active Directory qui contiennent déjà les informations des utilisateurs et leurs identifiants. À l’aide de la console d’administration, Keycloak peut être connecté à ces sources externes pour valider les identifiants et récupérer les informations d’identité.
Keycloak dispose d’une prise en charge native pour se connecter à des serveurs LDAP et Active Directory existants.
Il est également possible d’implémenter votre propre fournisseur si vos utilisateurs sont stockés dans d’autres systèmes, comme une base de données relationnelle.
D'accord, ça concerne les utilisateurs. Et les applications alors ?
Les applications ont également besoin d’authentification dans Keycloak, pas seulement les utilisateurs. Dans Keycloak (sans grande surprise), les applications sont appelées des clients.
Les clients peuvent être publics (aucune authentification au niveau de l’application n’est nécessaire) ou privés, ce qui signifie que pour chaque requête d’authentification, le client doit inclure dans la charge utile son client id et son secret configurés (une chaîne UUID qui agit comme un mot de passe pour le client). Si un client n’est pas connu de Keycloak, aucune authentification (et donc aucune autorisation) ne peut être délivrée. En d’autres termes, toutes les applications qui nécessitent une authentification avec un realm doivent être configurées comme des clients de ce realm.
Par ailleurs, une application peut permettre à des utilisateurs anonymes de naviguer dans ses ressources en s’authentifiant elle-même auprès de Keycloak en utilisant son client id et son secret, sans demander la connexion de l’utilisateur. Toutefois, cela reste un choix d’implémentation du propriétaire de l’application.
La console d'administration
Grâce à la console d’administration, les administrateurs peuvent gérer tous les aspects du serveur Keycloak à partir d’un seul endroit. Ils peuvent activer ou désactiver diverses fonctionnalités et :
- créer et gérer des utilisateurs, y compris leurs permissions et sessions
- configurer l’intermédiation d’identité et la fédération d’utilisateurs
- créer et gérer des applications et des services
- définir des politiques d’autorisation précises
L’un des aspects les plus utiles dans la gestion des utilisateurs provenant de fournisseurs d’identité externes est le mapping des attributs. En général, les attributs d’utilisateur exposés par des fournisseurs externes ne correspondent pas directement aux attributs natifs ou configurés dans notre système de gestion des utilisateurs internes.
Lors de la première connexion avec un fournisseur d’identité externe, le profil utilisateur est importé dans Keycloak, qui effectue un mapping des attributs entrants avec ceux configurés. La bonne nouvelle est que le mapping des attributs est une fonctionnalité propre à chaque fournisseur d’identité configuré dans Keycloak, ce qui signifie que chaque fournisseur d’identité pour lequel Keycloak agit en tant qu’intermédiaire peut avoir ses propres règles de mapping.
La console de gestion des comptes
Si le realm le permet (voir ci-dessus), les utilisateurs peuvent gérer leurs propres comptes via la console de gestion des comptes.
Les Protocoles
Keycloak est basé sur des protocoles solides et standards : comme mentionné précédemment, il prend en charge SAML, ainsi que OpenID Connect et OAuth 2.0.
SAML (Security Assertion Markup Language) est une norme ouverte pour échanger des données d’authentification et d’autorisation entre différentes parties, en particulier entre un fournisseur d’identité et un fournisseur de service.
C’est un langage de balisage basé sur XML utilisé pour les assertions de sécurité (déclarations que les fournisseurs de services utilisent pour prendre des décisions de contrôle d’accès).
OAuth 2.0, qui signifie “Open Authorization”, est une norme conçue pour permettre à un site web ou une application d’accéder à des ressources hébergées par d’autres applications web au nom d’un utilisateur. Il a remplacé OAuth 1.0 en 2012 et est désormais la norme de facto de l’industrie pour l’autorisation en ligne.
OpenID Connect est la troisième génération de la technologie OpenID. C’est une couche d’authentification construite sur le cadre d’autorisation OAuth 2.0. Elle permet aux clients informatiques de vérifier l’identité d’un utilisateur final en fonction de l’authentification effectuée par un serveur d’autorisation. En plus de cela, elle permet d’obtenir les informations de profil de base de l’utilisateur final.
D’un point de vue technique, OpenID Connect spécifie une API HTTP RESTful, utilisant JSON comme format de données.
Quelqu'un a-t-il mentionné un cluster ?
Avant de déployer Keycloak dans un environnement de production, vous devez décider du type de mode de fonctionnement que vous allez utiliser.
- Allez-vous exécuter Keycloak dans un cluster ?
- Souhaitez-vous une manière centralisée de gérer les configurations de vos serveurs ?
Mode autonome
Si nous voulons exécuter une seule instance de Keycloak, nous parlons du mode autonome.
Ce mode n’est pas adapté aux déploiements en cluster et n’est pas recommandé pour une utilisation en production, car il constitue un point de défaillance unique. Cependant, il constitue un bon moyen d’explorer les fonctionnalités et d’intégrer Keycloak dans votre environnement de serveur de développement.
Mode autonome en cluster
Si nous souhaitons exécuter Keycloak dans un cluster, le mode de fonctionnement le plus simple à déployer est le mode autonome en cluster. Cette méthode implique d’avoir :
- une instance Keycloak sur chaque machine participant au cluster, avec une connexion à une base de données partagée.
- une connexion à la base de données partagée entre toutes les instances Keycloak.
- un répartiteur de charge devant le cluster.
Cependant, cette configuration initiale simplifiée a un coût : pour effectuer un changement de configuration, il sera nécessaire de modifier chaque instance sur chaque machine.
Mode de cluster de domaine
Si vous cherchez à gérer et publier les configurations pour tous vos serveurs Keycloak depuis un seul endroit, nous parlons du mode de cluster de domaine.
Le point clé ici est que le choix entre un déploiement en cluster et des serveurs autonomes concerne avant tout la manière dont vos serveurs sont gérés, et non pas leur capacité à traiter les requêtes des utilisateurs finaux. En résumé, dans ce contexte, les fonctionnalités de haute disponibilité (HA) sont orthogonales au fait de faire fonctionner des serveurs autonomes ou un cluster. Autrement dit, un groupe de serveurs autonomes peut être configuré pour former un cluster HA. Les modes domain et standalone clustered déterminent la gestion des serveurs, pas les capacités qu’ils offrent.
Ce mode de fonctionnement implique deux rôles de serveur : le contrôleur de domaine et le contrôleur d’hôte.
Contrôleur de domaine
Dans le mode de cluster de domaine, il y a un processus responsable de la gestion, du stockage et de la fourniture de la configuration générale à chaque nœud Keycloak du cluster ; ce processus est le contrôleur de domaine. La présence de ce processus sur l’un des nœuds du cluster le désigne comme contrôleur de domaine. En résumé, ce processus est le point central du cluster à partir duquel les nœuds obtiennent leur configuration.
Contrôleur d'hôte
Une machine dans le cluster peut allouer une ou plusieurs instances, le contrôleur d’hôte est le processus chargé de gérer ces instances. Le contrôleur de domaine dialogue avec les contrôleurs d’hôte pour gérer le cluster. Habituellement, afin d’économiser des ressources, le contrôleur de domaine exécute également un contrôleur d’hôte et donc au moins une instance de serveur Keycloak. Lors du démarrage, chaque contrôleur d’hôte obtient sa configuration du contrôleur de domaine et démarre autant d’instances Keycloak qu’il a été configuré pour en lancer.
Conclusions
Dans cet article, nous avons couvert les principales fonctionnalités de Keycloak, un système de gestion des identités open source que l’on peut légitimement considérer comme le couteau suisse pour l’authentification, l’autorisation et l’intermédiation d’identité. Keycloak est tellement riche en fonctionnalités que chacune des fonctionnalités mentionnées dans cet article mériterait d’être décrite de manière exhaustive dans un article dédié.
Restez à l’écoute pour d’autres articles de SpazioCodice ! À bientôt !
