Dans toute grande entreprise, et X5 Retail Group ne fait pas exception, au fur et à mesure de son développement, le nombre de projets nécessitant une autorisation de l'utilisateur augmente. Au fil du temps, une transition transparente des utilisateurs d'une application à une autre est requise, 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 en identification" viendra à la rescousse. Les plus fonctionnels sont ses représentants, comme Keycloak, la gestion des accès Gravitee, etc. Le plus souvent, les cas d'utilisation peuvent être différents : interaction machine, participation des utilisateurs, etc. La solution doit supporter des fonctionnalités flexibles et évolutives pouvant combiner toutes les exigences en une seule, et de telles solutions, notre société dispose désormais d'un courtier d'indication - Keycloak.
Keycloak est un produit open source de contrôle d'identité et d'accès géré par RedHat. C'est la base des produits de l'entreprise utilisant SSO - RH-SSO.
Concepts de base
Avant de commencer à traiter des solutions et des approches, vous devez décider en termes et en séquence de processus :
Identification est une procédure de reconnaissance d'un sujet par son identifiant (autrement dit, c'est la définition d'un nom, d'un login ou d'un numéro).
Authentification - il s'agit d'une procédure d'authentification (l'utilisateur est contrôlé par un mot de passe, la lettre est contrôlée par une signature électronique, etc.)
AUTORISATION - il s'agit de la fourniture d'accès à une ressource (par exemple, au courrier électronique).
Keycloak de courtier d'identité
Cape de clé est une solution open source de gestion des identités et des accès conçue pour être utilisée dans les SI où des modèles d'architecture de microservices peuvent être utilisés.
Keycloak offre des fonctionnalités telles que l'authentification unique (SSO), l'identité négociée et la connexion sociale, la fédération d'utilisateurs, les adaptateurs clients, la console d'administration et la console de gestion de compte.
Fonctionnalité de base prise en charge par Keycloak :
- Single-Sign On et Single-Sign Out pour les applications de navigateur.
- Prise en charge d'OpenID/OAuth 2.0/SAML.
- Courtage d'identité - authentification à l'aide de fournisseurs d'identité OpenID Connect ou SAML externes.
- Connexion sociale - Prise en charge de Google, GitHub, Facebook, Twitter pour l'identification de l'utilisateur.
- Fédération d'utilisateurs - synchronisation des utilisateurs à partir des serveurs LDAP et Active Directory et d'autres fournisseurs d'identité.
- Pont Kerberos - utilisant un serveur Kerberos pour l'authentification automatique des utilisateurs.
- Console d'administration - pour une gestion unifiée des paramètres et des options de solution via le Web.
- Console de gestion de compte - pour l'auto-gestion du profil utilisateur.
- Personnalisation de la solution en fonction de l'identité visuelle de l'entreprise.
- Authentification 2FA - Prise en charge TOTP/HOTP à l'aide de Google Authenticator ou FreeOTP.
- Flux de connexion - l'auto-enregistrement de l'utilisateur, la récupération et la réinitialisation du mot de passe, et d'autres sont possibles.
- Gestion des sessions - les administrateurs peuvent gérer les sessions utilisateur à partir d'un point unique.
- Token Mappers - liant les attributs utilisateur, les rôles et autres attributs requis aux jetons.
- Gestion flexible des politiques à travers le domaine, l'application et les utilisateurs.
- Prise en charge CORS - Les adaptateurs clients ont une prise en charge CORS intégrée.
- Interfaces de fournisseur de services (SPI) - Un grand nombre de SPI qui vous permettent de personnaliser divers aspects du serveur : flux d'authentification, fournisseurs d'identité, mappage de protocole, etc.
- Adaptateurs clients pour les applications JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Prise en charge de l'utilisation de diverses applications prenant en charge la bibliothèque OpenID Connect Relying Party ou la bibliothèque de fournisseur de services SAML 2.0.
- Extensible à l'aide de plugins.
Pour les processus CI / CD, ainsi que l'automatisation des processus de gestion dans Keycloak, l'API REST / JAVA API peut être utilisée. La documentation est disponible en version électronique :
API REST
API JAVA
Fournisseurs d'identité d'entreprise (sur site)
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 des postes de travail avec Kerberos (LDAP ou AD), ils peuvent alors être automatiquement authentifiés auprès de Keycloak sans avoir à saisir à nouveau 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 s'applique le plus aux environnements de développement, car il n'implique pas de longs réglages et intégrations aux 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 à ce jour 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 un identifiant depuis les réseaux sociaux. Pour activer la possibilité d'authentifier les utilisateurs, utilisez la console d'administration Keycloack. Il n'est pas nécessaire de modifier le code de l'application et cette fonctionnalité est prête à l'emploi et peut être activée à n'importe quelle étape du projet.
Il est possible d'utiliser les fournisseurs d'identité OpenID/SAML pour l'authentification des utilisateurs.
Scénarios d'autorisation typiques utilisant OAuth2 dans Keycloak
Flux de code d'autorisation - utilisé avec des applications côté serveur. L'un des types d'autorisation les plus courants, car il est bien adapté aux applications serveur où le code source de l'application et les données client ne sont pas accessibles aux personnes extérieures. Le processus dans ce cas est basé sur la redirection. L'application doit pouvoir interagir avec un agent utilisateur (agent utilisateur), tel qu'un navigateur Web, pour recevoir les codes d'autorisation API redirigés via l'agent utilisateur.
Flux implicite - utilisé par des applications mobiles ou Web (applications exécutées sur l'appareil de l'utilisateur).
Le type d'autorisation d'autorisation implicite est utilisé par les applications mobiles et Web où la confidentialité du client ne peut pas être garantie. Le type d'autorisation implicite utilise également la redirection de l'agent utilisateur, dans laquelle 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. Ce type d'autorisation d'autorisation n'authentifie pas l'identité de l'application et le processus lui-même repose sur une URL de redirection (précédemment enregistrée auprès du service).
Le flux implicite ne prend pas en charge les jetons d'actualisation des jetons d'accès.
Flux d'attribution des informations d'identification du client — sont utilisés lorsque l'application accède à l'API. Ce type d'autorisation est généralement utilisé pour les interactions de serveur à serveur qui doivent être effectuées en arrière-plan sans interaction immédiate de l'utilisateur. Le flux d'octroi des informations d'identification du client permet à un service Web (client confidentiel) d'utiliser ses propres informations d'identification au lieu d'emprunter l'identité d'un utilisateur pour s'authentifier 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 identifiant.
La spécification OAuth2 est décrite dans
Jeton JWT et ses avantages
JWT (JSON Web Token) est un standard ouvert () qui définit un moyen compact et autonome de transférer en toute sécurité des 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, qui contient le type de jeton et le nom de l'algorithme de hachage permettant d'obtenir une signature numérique. La deuxième partie stocke les informations de base (utilisateur, attributs, etc.). La troisième partie est la signature numérique.
. .
Ne stockez jamais un jeton dans votre base de données. Étant donné qu'un jeton valide équivaut à un mot de passe, le stockage du jeton revient à stocker le mot de passe en texte clair.
Jeton d'accès est un jeton qui accorde à son propriétaire l'accès aux ressources du serveur sécurisé. Il a généralement une courte durée de vie et peut contenir des informations supplémentaires telles que l'adresse IP de la partie demandant le jeton.
Actualiser le jeton 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 de temps.
Les principaux avantages de l'utilisation dans une architecture de microservice :
- Possibilité d'accéder à diverses applications et services grâce à 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 pouvant être ajoutées à la charge utile, y compris de manière automatisée et à la volée.
- Il n'est pas nécessaire de stocker des informations sur les sessions actives, l'application serveur n'a qu'à vérifier la signature.
- Contrôle d'accès plus flexible grâce à 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
Titre - par défaut, l'en-tête ne contient que le type de jeton et l'algorithme utilisé pour le chiffrement.
Le type du jeton est stocké dans la clé "typ". La clé 'type' 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 Web Token JSON.
La deuxième clé "alg" définit l'algorithme utilisé pour chiffrer le jeton. Il doit être défini sur HS256 par défaut. L'en-tête est encodé en base64.
{ "alg": "HS256", "type": "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 "réclamation". Par exemple, vous pouvez participer à l'application uniquement sur invitation (promotion 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 le payload, pour cela nous la stockons dans la clé "email"
{ "e-mail": "[email protected]" }
Les clés de la charge utile peuvent être arbitraires. Cependant, il y a quelques réserves :
- iss (Issuer) - Identifie l'application à partir de laquelle le jeton est envoyé.
- sub (Sujet) - définit le sujet du jeton.
- aud (Audience) est un tableau de chaînes sensibles à la casse ou d'URI qui est une liste des destinataires de ce jeton. Lorsque le côté récepteur reçoit un JWT avec la clé donnée, il doit vérifier sa présence dans les destinataires - sinon ignorer le jeton.
- exp (Heure d'expiration) - Indique quand le jeton expire. La norme JWT exige que toutes ses implémentations rejettent les jetons expirés. La clé exp doit être un horodatage au format unix.
- nbf (Not Before) est une heure au format unix qui détermine le moment où le jeton devient valide.
- iat (Issued At) - 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 horodatage au format unix.
- Jti (ID JWT) — une chaîne qui définit l'identifiant unique de ce jeton, sensible à la casse.
Il est important de comprendre que la charge utile n'est pas transmise sous forme cryptée (bien que les jetons puissent être imbriqués et qu'il soit alors possible de transmettre des données cryptées). Par conséquent, il ne peut stocker aucune information secrète. Comme l'en-tête, la charge utile est encodée en base64.
signature - lorsque nous avons un titre 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 chaîne via un point. Ensuite, cette chaîne et la clé secrète sont entrées dans l'algorithme de chiffrement spécifié dans l'en-tête (clé "alg"). La clé peut être n'importe quelle chaîne. Les cordes plus longues seront les plus préférées car elles prendront plus de temps à ramasser.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Création d'une architecture de cluster de basculement Keycloak
Lors de l'utilisation d'un seul cluster pour tous les projets, les exigences en matière de solution SSO augmentent. Lorsque le nombre de projets est faible, ces exigences ne sont pas aussi perceptibles pour tous les projets, cependant, avec une augmentation du nombre d'utilisateurs et d'intégrations, les exigences de disponibilité et de performances augmentent.
L'augmentation du risque d'échec unique de SSO augmente les exigences en matière d'architecture de solution et les méthodes utilisées pour les composants redondants et conduit à un SLA très serré. À cet égard, le plus souvent pendant le développement ou les premières étapes de la mise en œuvre de solutions, les projets disposent de leur propre infrastructure non tolérante aux pannes. Au fur et à mesure que le développement progresse, il est nécessaire de définir des opportunités de développement et de mise à l'échelle. Il est plus flexible de créer un cluster de basculement à l'aide de la virtualisation de conteneurs ou d'une approche hybride.
Pour travailler dans les modes de cluster Actif/Actif et Actif/Passif, 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 tolérante aux pannes.
Quels sont les avantages d'utiliser un cluster unique :
- Haute disponibilité et performances.
- Prise en charge des modes de fonctionnement : Actif/Actif, Actif/Passif.
- Capacité à évoluer dynamiquement - lors de l'utilisation de la virtualisation de conteneurs.
- Possibilité de gestion et de suivi centralisés.
- Approche unifiée pour l'identification/l'authentification/l'autorisation des utilisateurs dans les projets.
- Interaction plus transparente entre différents projets sans implication des utilisateurs.
- La possibilité de réutiliser le jeton JWT dans divers projets.
- Point de confiance unique.
- Lancement plus rapide des projets utilisant les microservices/la virtualisation des conteneurs (pas besoin de soulever et de configurer des composants supplémentaires).
- Il est possible d'acheter une assistance commerciale auprès du fournisseur.
Que rechercher lors de la planification d'un cluster
SGBD
Keycloak utilise un système de gestion de base de données pour stocker : domaines, clients, utilisateurs, etc.
Une large gamme de SGBD est supportée : MS SQL, Oracle, MySQL, PostgreSQL. Keycloak est livré avec sa propre base de données relationnelle intégrée. Il est recommandé de l'utiliser pour les environnements non chargés, tels que les environnements de développement.
Pour travailler dans les modes de cluster Actif/Actif et Actif/Passif, la cohérence des données dans une base de données relationnelle est requise, et les deux nœuds de 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 caches suivants à l'aide de JBoss Data Grid est requise :
Sessions d'authentification - utilisées pour enregistrer des données lors de l'authentification d'un utilisateur spécifique. Les requêtes provenant de ce cache n'incluent généralement que le navigateur et le serveur Keycloak, pas l'application.
Les jetons d'action sont utilisés pour les scénarios où l'utilisateur doit confirmer une action de manière asynchrone (par e-mail). Par exemple, lors d'un flux d'oubli de mot de passe, le cache actionTokens Infinispan est utilisé pour garder une trace des métadonnées sur les jetons d'action associés qui ont déjà été utilisés, de sorte qu'il ne peut pas être réutilisé.
Mise en cache et invalidation des données persistantes - utilisé pour mettre en cache les données persistantes afin d'éviter les requêtes inutiles à la base de données. Lorsqu'un serveur Keycloak met à jour les données, tous les autres serveurs Keycloak de tous les centres de données doivent en être informés.
Work - Uniquement utilisé pour envoyer des messages non valides entre les nœuds de cluster et les centres de données.
Sessions utilisateur - utilisé pour stocker des données sur les sessions utilisateur qui sont valides pour la durée de la session de navigateur de l'utilisateur. Le cache doit traiter les requêtes HTTP de l'utilisateur final et de l'application.
Protection contre la force brute - utilisée pour suivre les données sur les échecs de connexion.
L'équilibrage de charge
L'équilibreur de charge est le point d'entrée unique du keycloak et doit prendre en charge les sessions permanentes.
Serveurs d'applications
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 de la mise à l'échelle dynamique des outils d'automatisation de l'infrastructure. Les scénarios de déploiement les plus courants dans OpenShift, Kubernates, Rancher.
Ceci conclut la première partie - la partie théorique. Dans la prochaine série d'articles, des exemples d'intégrations avec divers fournisseurs d'identité et des exemples de paramètres seront analysés.
Source: habr.com