SSO sur une architecture microservices. Utilisation de Keycloak. Partie n°1

Dans toute grande entreprise, y compris le groupe X5 Retail, au fur et à mesure de leur développement, le nombre de projets nécessitant une authentification des utilisateurs augmente. Avec le temps, un passage fluide des utilisateurs d'une application à une autre devient essentiel, rendant nécessaire l'utilisation d'un serveur d'authentification unique, le Single-Sign-On (SSO). Mais que faire lorsque des fournisseurs d'identité comme AD, ou d'autres n'ayant pas d'attributs supplémentaires, sont déjà utilisés dans divers projets ? C'est ici qu'interviennent les classes de systèmes appelées « courtiers d'identité ». Les représentants les plus fonctionnels de ce système incluent Keycloak, Gravitee Access management, etc. Les scénarios d'utilisation peuvent être variés : interaction machine, participation des utilisateurs, etc. La solution doit prendre en charge une fonctionnalité flexible et évolutive, capable de répondre à toutes les exigences en un seul endroit, et c'est ce que représente actuellement le courtier d'identité dans notre société – Keycloak.

Keycloak est un produit open source destiné à l'identification et à la gestion des accès, soutenu par la société RedHat. Il constitue la base des produits de l'entreprise utilisant le SSO – RH-SSO.

Concepts de base

Avant de commencer à examiner les solutions et les approches, il convient de clarifier les termes et la séquence des processus :

Identification – c'est la procédure de reconnaissance d'un sujet par son identifiant (en d'autres termes, il s'agit de déterminer le nom, le login ou le numéro).

Authentification – c'est la procédure de vérification de l'authenticité (l'utilisateur est vérifié par son mot de passe, un document électronique est vérifié par une signature électronique, etc.)

Autorisation – c'est l'octroi d'accès à une ressource particulière (par exemple, à un courriel).

Le courtier d'identité Keycloak

Keycloak est une solution de gestion des identités et des accès open source, conçue pour être utilisée dans des systèmes d'information pouvant intégrer des modèles d'architecture microservices.

Keycloak propose des fonctionnalités telles que l'authentification unique (SSO), l'identification via un courtier et la connexion sociale, la fédération des utilisateurs, des adaptateurs client, une console d'administration et une console de gestion des comptes.

Fonctionnalité de base prise en charge dans Keycloak :

• Single-Sign On et Single-Sign Out pour les applications web.
• Support d'OpenID/OAuth 2.0/SAML.
• Rassemblement d'identité – authentification via des fournisseurs d'identité externes OpenID Connect ou SAML.
• Connexion sociale – prise en charge de Google, GitHub, Facebook, Twitter pour l'identification des utilisateurs.
• Fédération d'utilisateurs – synchronisation des utilisateurs à partir des serveurs LDAP et Active Directory et d'autres fournisseurs d'identité.
• Pont Kerberos – utilisation du serveur Kerberos pour l'authentification automatique des utilisateurs.
• Console d'administration — pour la gestion centralisée des paramètres et options de la solution via le Web.
• Console de gestion des comptes – pour une gestion autonome des profils utilisateurs.
• Personnalisation de la solution en fonction de l'identité de l'entreprise.
• Authentification 2FA – prise en charge de TOTP/HOTP avec Google Authenticator ou FreeOTP.
• Flux de connexion – possibilité d'auto-inscription des utilisateurs, de récupération et de réinitialisation de mot de passe, etc.
• Gestion des sessions – les administrateurs peuvent gérer les sessions des utilisateurs à partir d'un point central.
• Mappeurs de jetons – association des attributs des utilisateurs, des rôles et d'autres attributs requis dans les jetons.
• Gestion flexible des politiques via le realm, l'application et les utilisateurs.
• Support CORS – les adaptateurs clients disposent d'un support CORS intégré.
• Interfaces de fournisseur de services (SPI) – un grand nombre de SPI permettant de configurer différents aspects du fonctionnement du serveur : flux d'authentification, fournisseurs d'identité, mappage de protocoles, etc.
• Adaptateurs clients pour les applications JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Support pour les applications utilisant la bibliothèque OpenID Connect Relying Party ou la bibliothèque SAML 2.0 Service Provider.
• Possibilité d'extension avec des plugins.

Pour les processus CI/CD ainsi que pour l'automatisation de la gestion dans Keycloak, l'API REST/JAVA API peut être utilisée. La documentation est disponible sous forme électronique :

API REST https://www.keycloak.org/docs-api/8.0/rest-api/index.html
API JAVA https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Fournisseurs d'identité de niveau entreprise (On-Premise)

Possibilité d'authentification des utilisateurs via des services de fédération d'utilisateurs.

L'authentification unique peut également être utilisée — si les utilisateurs sont authentifiés sur des stations de travail avec Kerberos (LDAP ou AD), ils peuvent être automatiquement authentifiés sur Keycloak sans avoir à ressaisir leur nom d'utilisateur et mot de passe.

Pour l'authentification et l'autorisation ultérieure des utilisateurs, il est possible d'utiliser une base de données relationnelle, ce qui est particulièrement adapté aux environnements de développement, car cela n'entraîne pas de configurations et d'intégrations prolongées aux premières étapes des projets. Par défaut, Keycloak utilise une base de données intégrée pour stocker les paramètres et les données des utilisateurs.

La liste des bases de données supportées est vaste et inclut : MS SQL, Oracle, PostgreSQL, MariaDB, Oracle et d'autres. Les plus testées à ce jour sont Oracle 12C Release 1 RAC et le cluster Galera 3.12 pour MariaDB 10.1.19.

Fournisseurs d'identification — connexion sociale

Il est possible d'utiliser un identifiant provenant des réseaux sociaux. Pour activer la possibilité d'authentifier les utilisateurs, la console d'administration de Keycloak est utilisée. Aucun changement dans le code des applications n'est nécessaire et cette fonctionnalité est disponible 'out of the box' et peut être activée à tout stade de la réalisation du projet.

Pour l'authentification des utilisateurs, il est possible d'utiliser des fournisseurs d'identité OpenID/SAML.

Scénarios d'autorisation typiques utilisant OAuth2 dans Keycloak

Flux de code d'autorisation — utilisé avec des applications serveur (applications côté serveur). C'est l'un des types les plus courants d'autorisation, car il convient particulièrement bien aux applications serveur dont le code source et les données client ne sont pas accessibles à des tiers. Le processus repose sur la redirection. L'application doit être capable d'interagir avec l'agent utilisateur, tel qu'un navigateur web — en obtenant des codes d'autorisation API redirigés via l'agent utilisateur.

Flux implicite — utilisé par des applications mobiles ou web (applications fonctionnant sur l'appareil de l'utilisateur).

Le type de permission implicite est utilisé par les applications mobiles et web où la confidentialité du client ne peut pas être garantie. Ce type de permission utilise également la redirection de l'agent utilisateur, le jeton d'accès étant transmis à l'agent utilisateur pour une utilisation ultérieure dans l'application. Cela rend le jeton accessible à l'utilisateur et à d'autres applications sur l'appareil de l'utilisateur. Avec ce type de permission, l'authentification de l'application n'est pas effectuée, le processus reposant sur l'URL de redirection (enregistrée auparavant dans le service).

Le Flux Implicite ne supporte pas les jetons de rafraîchissement (refresh tokens).

Flux d'Octroi de Credentials Client — utilisé lors de l'accès de l'application à l'API. Ce type de permission est généralement utilisé pour les interactions « serveur-serveur », qui doivent se dérouler en arrière-plan sans interaction immédiate avec l'utilisateur. Le flux de fourniture d'identifiants client permet à un service web (client confidentiel) d'utiliser ses propres identifiants au lieu de l'authentification de l'utilisateur lors de l'appel d'un autre service web. Pour un niveau de sécurité supérieur, il est possible que le service appelant utilise un certificat (au lieu d'un secret partagé) comme identifiant.

La spécification OAuth2 est décrite dans
RFC-6749
RFC-8252
RFC-6819

Jeton JWT et ses avantages

JWT (JSON Web Token) est une norme ouverte (https://tools.ietf.org/html/rfc7519), qui définit un moyen compact et autonome pour la transmission sécurisée d'informations entre les parties sous la forme d'un objet JSON.

Selon la norme, le jeton se compose de trois parties au format base-64, séparées par des points. La première partie s'appelle l'en-tête (header), qui contient le type de jeton et le nom de l'algorithme de hachage utilisé pour produire la signature numérique. La deuxième partie contient l'information principale (utilisateur, attributs, etc.). La troisième partie est la signature numérique.

..
Ne stockez jamais de jeton dans votre BDD. Un jeton valide est équivalent à un mot de passe, stocker un jeton revient à stocker un mot de passe en clair.
Jeton d'accès — c'est un jeton qui donne à son titulaire accès aux ressources protégées du serveur. Il a généralement une durée de vie courte et peut contenir des informations supplémentaires, comme l'adresse IP de la partie demandant ce jeton.

Jeton de rafraîchissement — c'est un jeton qui permet aux clients de demander de nouveaux jetons d'accès après leur période de validité. Ces jetons sont généralement délivrés pour une longue durée.

Principaux avantages d'une telle application dans une architecture microservices :

• Possibilité d'accéder à différentes applications et services par le biais d'une authentification unique.
• En l'absence de certains attributs requis dans les profils utilisateur, il est possible d'enrichir les données, y compris automatiquement et 'à la volée'.
• Pas besoin de stocker des informations sur les sessions actives ; l'application serveur doit simplement vérifier la signature.
• Gestion des accès plus flexible grâce à des attributs supplémentaires dans la charge utile.
• L'utilisation de la signature du jeton pour l'en-tête et la charge utile renforce la sécurité de la solution dans son ensemble.

Jeton JWT — composant

L'en-tête — par défaut, l'en-tête contient uniquement le type de jeton et l'algorithme utilisé pour le chiffrement.

Le type de jeton est stocké dans la clé « typ ». La clé « typ » est ignorée dans JWT. Si la clé « typ » est présente, sa valeur doit être JWT pour indiquer que cet objet est un JSON Web Token.

La deuxième clé « alg » définit l'algorithme utilisé pour chiffrer le jeton. Par défaut, il doit être défini sur HS256. L'en-tête est codé en base64.

{ "alg": "HS256", "typ": "JWT"}
Charge utile (contenu) — dans la charge utile est stockée toute information à vérifier. Chaque clé dans la charge utile est connue sous le nom de « déclaration ». Par exemple, on peut entrer dans l'application uniquement sur invitation (promotion fermée). Lorsque nous voulons inviter quelqu'un à participer, nous lui envoyons un courriel d'invitation. Il est important de vérifier que l'adresse électronique appartient à la personne qui accepte l'invitation, donc nous allons inclure cette adresse dans la charge utile, en la sauvegardant sous la clé « e-mail »

{ "email": "example@x5.fr" }

Les clés dans la charge utile peuvent être arbitraires. Cependant, il y a plusieurs réservées :

• iss (Émetteur) — détermine l'application à partir de laquelle le jeton est envoyé.
• sub (Sujet) — définit le sujet du jeton.
• aud (Audience) – un tableau de chaînes sensibles à la casse ou d'URI, représentant la liste des destinataires de ce jeton. Lorsque le destinataire reçoit un JWT avec cette clé, il doit vérifier sa présence parmi les destinataires, sinon ignorer le jeton.
• exp (Heure d'expiration) — indique quand le jeton expire. La norme JWT exige que, dans toutes ses implémentations, les jetons expirés soient rejetés. La clé exp doit être un timestamp au format unix.
• nbf (Non avant) — un temps au format unix, définissant le moment où le jeton deviendra valide.
• iat (Émis à) — cette clé représente l'heure à laquelle le jeton a été émis et peut être utilisée pour déterminer l'âge du JWT. La clé iat doit être un timestamp au format unix.
• Jti (ID JWT) — chaîne définissant un identifiant unique pour ce jeton, sensible à la casse.

Il est important de comprendre que la charge utile n'est pas transmise de manière chiffrée (bien que les jetons puissent être imbriqués et ainsi permettre de transmettre des données chiffrées). Par conséquent, elle ne doit pas contenir d'informations sensibles. Comme pour l'en-tête, la charge utile est encodée en base64.
Signature — lorsque nous avons l'en-tête et la charge utile, nous pouvons calculer la signature.

Les éléments codés en base64 : l'en-tête et la charge utile sont combinés en une seule chaîne à l'aide d'un point. Ensuite, cette chaîne et la clé secrète sont entrées dans l'algorithme de cryptage spécifié dans l'en-tête (clé « alg »). La clé peut être n'importe quelle chaîne. Des chaînes plus longues seront préférables, car elles nécessiteront plus de temps pour être déchiffrées.

{"alg":"RSA1_5", "payload":"A128CBC-HS256"}

Construction de l'architecture d'un cluster Keycloak tolérant aux pannes

Lorsque l'on utilise un seul cluster pour tous les projets, les exigences pour la solution SSO augmentent. Quand le nombre de projets est faible, ces exigences ne sont pas très marquées pour tous les projets, mais à mesure que le nombre d'utilisateurs et d'intégrations augmente, les exigences en matière de disponibilité et de performance s'intensifient.

L'augmentation des risques de défaillance du SSO unique renforce les exigences en matière d'architecture des solutions et des méthodes de redondance des composants, entraînant des SLA très stricts. En conséquence, il est fréquent que lors du développement ou des premières étapes de mise en œuvre des solutions, des projets possèdent leur propre infrastructure non redondante. Au fur et à mesure de l'évolution, il est nécessaire de prévoir des capacités de développement et de mise à l'échelle. Il est plus flexible de construire un cluster tolérant aux pannes en utilisant la virtualisation par conteneurs ou une approche hybride.

Pour fonctionner en mode Active/Active et Active/Passive, le cluster doit garantir la cohérence des données dans la base de données relationnelle — les deux nœuds de la base de données doivent être répliqués de manière synchrone entre différents centres de données géo-distribués.

L'exemple le plus simple d'une installation tolérante aux pannes.

Quels sont les avantages d'utiliser un cluster unique :

• Haute disponibilité et performance.
• Support des modes de fonctionnement : Active/Active, Active/Passive.
• Possibilité d'évolutivité dynamique — lors de l'utilisation de la virtualisation par conteneurs.
• Possibilité de gestion et de surveillance centralisées.
• Une approche unique pour l'identification/authentification/autorisation des utilisateurs dans les projets.
• Une interaction plus transparente entre différents projets sans intervention des utilisateurs.
• Possibilité de réutilisation du token JWT dans différents projets.
• Un point de confiance unique.
• Lancement plus rapide des projets en utilisant des microservices/virtualisation par conteneurs (pas besoin de déployer et configurer des composants supplémentaires).
• Possibilité d'acquérir un support commercial auprès du fournisseur.

À quoi faire attention lors de la planification d'un cluster

SGBD

Keycloak utilise un système de gestion de SGBD pour sauvegarder : realms, clients, utilisateurs, etc.
Un large éventail de SGBD est supporté : MS SQL, Oracle, MySQL, PostgreSQL. Keycloak est fourni avec sa propre base de données relationnelle intégrée. Son utilisation est recommandée pour les environnements peu chargés — tels que les environnements de développement.

Pour fonctionner en mode Active/Active et Active/Passive, le cluster doit garantir la cohérence des données dans la base de données relationnelle, et les deux nœuds du cluster de bases de données sont répliqués de manière synchrone entre les centres de données.

Cache distribué (Infinispan)

Pour un bon fonctionnement du cluster, une synchronisation supplémentaire des types de cache suivants est requise à l'aide de JBoss Data Grid :

Sessions d'authentification — utilisées pour stocker les données lors de l'authentification d'un utilisateur spécifique. Les requêtes provenant de ce cache incluent généralement uniquement le navigateur et le serveur Keycloak, mais pas l'application.

Tokens d'action — utilisés pour des scénarios où l'utilisateur doit confirmer une action de manière asynchrone (par email). Par exemple, lors du processus de réinitialisation de mot de passe, le cache actionTokens Infinispan est utilisé pour suivre les métadonnées concernant les tokens d'action associés qui ont déjà été utilisés, de sorte qu'ils ne peuvent pas être réutilisés.

Mise en cache et invalidation des données persistantes – utilisées pour mettre en cache des données permanentes afin d'éviter les requêtes excessives à la base de données. Lorsque l'un des serveurs Keycloak met à jour des données, tous les autres serveurs Keycloak dans tous les centres de données doivent en être informés.

Travail — uniquement utilisé pour envoyer des messages d'invalidation entre les nœuds du cluster et les centres de données.

Sessions utilisateur — utilisées pour conserver les données sur les sessions des utilisateurs qui sont valides pendant la session de leur navigateur. Le cache doit traiter les requêtes HTTP provenant de l'utilisateur final et de l'application.

Protection contre les attaques par force brute — utilisée pour suivre les données concernant les tentatives de connexion échouées.

Équilibrage de charge

Le répartiteur de charge est un point d'entrée unique dans Keycloak et doit prendre en charge les sessions persistantes.

Serveurs d'applications

Utilisés pour contrôler l'interaction entre les composants et peuvent être virtualisés ou conteneurisés à l'aide des outils d'automatisation existants et de l'évolutivité dynamique des infrastructures automatisées. Les scénarios de déploiement les plus courants sont dans OpenShift, Kubernetes, Rancher.

Voici la première partie — théorique — qui est terminée. Dans les prochains cycles d'articles, des exemples d'intégrations avec divers fournisseurs d'identités et des exemples de configurations seront examinés.

Source : habr.com