🎊 👉🏼 🤑 SSO sur l'architecture de microservice. Nous utilisons Keycloak. Numéro de pièce 1 ⏮️ 🍭 👨🏿

Dans toute grande entreprise, le X5 Retail Group ne fait pas exception, car le nombre de projets nécessitant une authentification des utilisateurs augmente à mesure que le nombre de projets augmente. Au fil du temps, une transition transparente des utilisateurs d'une application à une autre est nécessaire, puis il est nécessaire d'utiliser un seul serveur Single-Sing-On (SSO). Mais qu'en est-il lorsque des fournisseurs d'identité tels que AD ou d'autres qui n'ont pas d'attributs supplémentaires sont déjà utilisés dans divers projets. Une classe de systèmes appelés «courtiers d'identité» viendra à la rescousse. Les plus fonctionnels sont ses représentants, tels que Keycloak, Gravitee Access management, etc. Le plus souvent, les scénarios d'utilisation peuvent être différents: interaction machine, participation des utilisateurs, etc. La solution doit supporter des fonctionnalités flexibles et évolutives,capable de combiner toutes les exigences en une seule, et une telle solution dans notre entreprise est maintenant un courtier indicateur - Keycloak.

Keycloak est un produit open source pour l'authentification et le contrôle d'accès pris en charge par RedHat. C'est la base des produits de l'entreprise utilisant SSO - RH-SSO.

Concepts de base

Avant de commencer à traiter des décisions et des approches, vous devez déterminer les termes et la séquence des processus: L'

identification est le processus de reconnaissance d'un sujet par son identifiant (en d'autres termes, il détermine un nom, un identifiant ou un numéro).

L'authentification est une procédure d'authentification (un utilisateur est vérifié avec un mot de passe, une lettre est vérifiée par signature électronique, etc.) L'

autorisation est la fourniture d'accès à une ressource (par exemple, un courrier électronique).

Courtier d'identité Keycloak

Keycloak est une solution open source de gestion des identités et des accès conçue pour être utilisée dans les circuits intégrés où des modèles d'architecture de microservices peuvent être utilisés.

Keycloak offre des fonctionnalités telles que l'authentification unique (SSO), l'identification du courtier et la connexion sociale, la fédération des utilisateurs, les adaptateurs client, une console d'administrateur et une console de gestion de compte.

Fonctionnalité de base prise en charge dans Keycloak:

Authentification unique et déconnexion unique pour les applications basées sur un navigateur.
Prise en charge d'OpenID / OAuth 2.0 / SAML.
Courtage d'identité - Authentification à l'aide de fournisseurs d'identité OpenID Connect externes ou SAML.
Connexion sociale - prise en charge de Google, GitHub, Facebook, Twitter pour l'identification des utilisateurs.
User Federation – LDAP Active Directory .
Kerberos bridge – Kerberos .
Admin Console — Web.
Account Management Console – .
.
2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
Login Flows – , .
Session Management – .
Token Mappers – , .
realm, application .
CORS Support – CORS.
Service Provider Interfaces (SPI) – SPI, : , , .
JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
, OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
plugins.

Pour les processus CI / CD, ainsi que l'automatisation des processus de gestion dans Keycloak, l'API REST / API JAVA 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é d'entreprise (sur site)

La possibilité d'authentifier les utilisateurs via les services de fédération d'utilisateurs.

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

Pour l'authentification et l'autorisation supplémentaire des utilisateurs, il est possible d'utiliser un SGBD relationnel, qui est le plus applicable aux environnements de développement, car il n'implique pas de paramètres et d'intégrations à long terme dans les premières étapes des projets. Par défaut, Keycloak utilise un SGBD intégré pour stocker les paramètres et les données utilisateur.

La liste des SGBD pris en charge est longue et comprend: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle et autres. Les plus testés actuellement sont Oracle 12C Release1 RAC et le cluster Galera 3.12 pour MariaDB 10.1.19.

Fournisseurs d'identité - connexion sociale

Il est possible d'utiliser une connexion depuis les réseaux sociaux. Pour activer la possibilité d'authentifier les utilisateurs, la console d'administration Keycloack est utilisée. Il n'est pas nécessaire de modifier le code de l'application et cette fonctionnalité est disponible «prête à l'emploi» et peut être activée à n'importe quelle étape du projet.

Pour authentifier les utilisateurs, il est possible d'utiliser des fournisseurs d'identités OpenID / SAML.

Scénarios d'autorisation typiques utilisant OAuth2 dans Keycloak

Flux de code d'autorisation - utilisé avec les applications côté serveur. L'un des types d'autorisation les plus courants, car il convient bien aux applications serveur dans lesquelles le code source de l'application et les données client ne sont pas accessibles aux étrangers. Dans ce cas, le processus est basé sur la redirection. L'application doit pouvoir interagir avec l'agent utilisateur (user-agent), tel qu'un navigateur Web, pour recevoir des codes d'autorisation API redirigés via l'agent utilisateur.

Flux implicite - utilisé par les applications mobiles ou Web (applications s'exécutant sur l'appareil de l'utilisateur).

Un type implicite d'autorisation d'autorisation est utilisé par les applications mobiles et Web où la confidentialité des clients ne peut pas être garantie. Le type d'autorisation implicite utilise également la redirection de l'agent utilisateur et le jeton d'accès est transmis à l'agent utilisateur pour une utilisation ultérieure dans l'application. Cela rend le jeton disponible pour l'utilisateur et d'autres applications sur l'appareil de l'utilisateur. Avec ce type d'autorisation, l'application n'est pas authentifiée et le processus lui-même repose sur une URL de redirection (précédemment enregistrée dans le service).

Le flux implicite ne prend pas en charge les jetons d'actualisation.
Flux d'octroi des informations d'identification client - utilisé lorsque l'application accède à l'API. Ce type d'autorisation est généralement utilisé pour les interactions de serveur à serveur qui doivent s'exécuter en arrière-plan sans interaction immédiate avec l'utilisateur. Le flux d'informations d'identification du client permet au service Web (le client confidentiel) d'utiliser ses propres informations d'identification au lieu d'usurper l'identité de l'utilisateur pour l'authentification lors de l'appel d'un autre service Web. Pour un niveau de sécurité plus élevé, il est possible que le service appelant utilise un certificat (au lieu d'un secret partagé) comme informations d'identification.

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

Jeton JWT et ses avantages

JWT (JSON Web Token) est un standard ouvert ( https://tools.ietf.org/html/rfc7519 ) qui définit une méthode compacte et autonome pour transférer en toute sécurité des informations entre les parties en tant qu'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 est appelée en-tête, qui contient le type de jeton et le nom de l'algorithme de hachage pour obtenir une signature numérique. La deuxième partie stocke les informations de base (utilisateur, attributs, etc.). La troisième partie est une signature numérique.

<en-tête codé>. <charge utile codée>. <signature>
N'enregistrez jamais de jeton dans votre base de données. Étant donné qu'un jeton valide est équivalent à un mot de passe, le stockage d'un jeton revient à stocker un mot de passe en texte clair.
Un jeton d'accès est un jeton qui donne à son propriétaire un accès aux ressources protégées du serveur. Habituellement, il a une courte durée de vie et peut contenir des informations supplémentaires, telles que l'adresse IP de la partie demandant ce jeton.

Un jeton d'actualisation est un jeton qui permet aux clients de demander de nouveaux jetons d'accès après l'expiration de leur durée de vie. Ces jetons sont généralement émis pour une longue période.

Principaux avantages de l'application en architecture de microservices:

La possibilité d'accéder à diverses applications et services via une authentification unique.
En l'absence d'un certain nombre d'attributs requis dans le profil utilisateur, il est possible d'enrichir avec des données qui peuvent être ajoutées à la charge utile, y compris automatisées et à la volée.
Il n'est pas nécessaire de stocker des informations sur les sessions actives, l'application serveur doit uniquement vérifier la signature.
Contrôle d'accès plus flexible avec des attributs supplémentaires dans la charge utile.
L'utilisation d'une signature de jeton pour l'en-tête et la charge utile augmente la sécurité de la solution dans son ensemble.

Jeton JWT - Composition

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 le JWT. Si la clé typ est présente, sa valeur doit être JWT pour indiquer que cet objet est un jeton Web JSON.

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) - la charge utile stocke toutes les informations qui doivent être vérifiées. Chaque clé de la charge utile est appelée «instruction». Par exemple, la candidature ne peut être saisie que sur invitation (promo fermée). Lorsque nous voulons inviter quelqu'un à participer, nous lui envoyons une lettre d'invitation. Il est important de vérifier que l'adresse e-mail appartient à la personne qui accepte l'invitation, nous inclurons donc cette adresse dans la charge utile, pour cela nous l'enregistrerons dans la clé «e-mail»

{"email": "example@x5.ru"}
Les clés de la charge utile peuvent être arbitraires. Cependant, il y en a quelques-uns réservés:

iss (Issuer) - définit l'application à partir de laquelle le jeton est envoyé.
sub (Subject) - définit le sujet du jeton.
aud (Audience) – URI, . JWT , — .
exp (Expiration Time) — , . JWT , . Exp unix .
nbf (Not Before) — unix , , .
iat (Issued At) — , JWT. iat unix .
Jti (JWT ID) — , c .

Il est important de comprendre que la charge utile n'est pas transmise sous forme cryptée (bien que les jetons puissent être intégrés et qu'il soit alors possible de transmettre des données cryptées). Par conséquent, il est impossible d'y stocker des informations secrètes. Comme l'en-tête, la charge utile est codée en base64.
Signature - lorsque nous avons un en-tête et une charge utile, nous pouvons calculer la signature.

Encodé en Base64: l'en-tête et la charge utile sont pris, ils sont combinés en une ligne par un point. Ensuite, cette ligne et la clé secrète sont envoyées à l'entrée de l'algorithme de chiffrement spécifié dans l'en-tête (clé "alg"). La clé peut être n'importe quelle chaîne. Des cordes plus longues seront préférables, car cela prendra plus de temps pour correspondre.

{"alg": "RSA1_5", "charge utile": "A128CBC-HS256"}

Architecture du cluster de basculement Keycloak

Lorsque vous utilisez un seul cluster pour tous les projets, il existe des exigences accrues pour une solution d'authentification unique. Lorsque le nombre de projets est faible, ces exigences ne sont pas si perceptibles pour tous les projets, mais avec une augmentation du nombre d'utilisateurs et d'intégrations, les exigences d'accessibilité et de productivité augmentent.

L'augmentation du risque de défaillance d'un SSO unique augmente les exigences pour l'architecture de la solution et les méthodes utilisées pour la redondance des composants et conduit à un SLA très serré. À cet égard, plus souvent lors du développement ou dans les premiers stades de la mise en œuvre de solutions, les projets ont leur propre infrastructure non tolérante aux pannes. Au fur et à mesure de votre développement, vous devez prévoir la possibilité de développement et de mise à l'échelle. Le plus flexible est de créer un cluster de basculement à l'aide de la virtualisation de conteneurs ou d'une approche hybride.

Pour travailler dans des clusters actifs / actifs et actifs / passifs, il est nécessaire d'assurer la cohérence des données dans une base de données relationnelle - les deux nœuds de 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 à sécurité intégrée.

Quels sont les avantages d'utiliser un seul cluster:

Haute disponibilité et performances.
Prise en charge des modes de fonctionnement: actif / actif, actif / passif.
La possibilité d'évoluer dynamiquement - lors de l'utilisation de la virtualisation de conteneurs.
Possibilité de gestion et de surveillance centralisées.
Approche unifiée pour l'identification / l'authentification / l'autorisation des utilisateurs dans les projets.
Interaction plus transparente entre différents projets sans participation des utilisateurs.
La possibilité de réutiliser le jeton JWT dans divers projets.
Point de confiance unique.
Lancement plus rapide de projets utilisant la virtualisation de microservices / conteneurs (pas besoin de monter et configurer des composants supplémentaires).
Peut-être l'acquisition d'un support commercial auprès du vendeur.

Éléments à prendre en compte lors de la planification d'un cluster

SGBD

Keycloak utilise un système de gestion de SGBD pour sauvegarder: domaines, clients, utilisateurs, etc.
Une large gamme de SGBD est prise en charge: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak est livré avec sa propre base de données relationnelle intégrée. L'utilisation pour les environnements non chargés tels que les environnements de développement est recommandée.

Pour fonctionner dans des clusters actifs / actifs et actifs / passifs, il est nécessaire de garantir la cohérence des données dans une base de données relationnelle, et les deux nœuds du cluster de base de données sont répliqués de manière synchrone entre les centres de données.

Cache distribué (Infinspan)

Pour que le cluster fonctionne correctement, une synchronisation supplémentaire des types de cache suivants à l'aide de JBoss Data Grid est requise:

Sessions d'authentification - utilisées pour enregistrer les données lors de l'authentification d'un utilisateur spécifique. Les demandes de ce cache incluent généralement uniquement le navigateur et le serveur Keycloak, pas l'application.

Jetons d'action - utilisés pour les scénarios où l'utilisateur doit confirmer l'action de manière asynchrone (par e-mail). Par exemple, pendant le flux de mot de passe oublié, le cache actionTokens Infinispan est utilisé pour suivre les métadonnées sur les marqueurs d'action associés qui ont déjà été utilisés, il ne peut donc pas être réutilisé.

Mise en cache et invalidation des données persistantes - utilisé pour mettre en cache les données persistantes pour éviter les requêtes de base de données inutiles. Lorsqu'un serveur Keycloak met à jour des données, tous les autres serveurs Keycloak de tous les centres de données doivent en être conscients.

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

Sessions utilisateur - utilisées pour enregistrer des données sur les sessions utilisateur valides pour la session de navigation d'un utilisateur. Le cache doit gérer les requêtes HTTP de l'utilisateur final et de l'application.

Protection contre la force brute - utilisée pour suivre les données de connexion ayant échoué.

L'équilibrage de charge

L'équilibreur de charge est un point d'entrée unique dans keycloak et devrait prendre en charge les sessions persistantes.

Serveur d'application

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

Sur ce point, la première partie - théorique - est terminée. Dans la série d'articles suivante, des exemples d'intégration avec divers fournisseurs d'identification et des exemples de configuration seront discutés.

SSO sur l'architecture de microservice. Nous utilisons Keycloak. Numéro de pièce 1