Comment ca va?
Et bon retour.
Maintenant, dans la vidéo d'aujourd'hui, nous allons discuter du concept de fédération.
Maintenant, avant d'aller de l'avant et d'examiner cela plus en détail, prenons un cas d'utilisation
simple pour comprendre le défi auquel sont confrontés des millions de personnes et la plupart des organisations à grande échelle.
Supposons donc qu'il y ait 500 utilisateurs au sein de votre organisation et que cette organisation utilise
activement trois services principaux.
Le premier est l'aide, au moins pour les infrastructures.
Le deuxième est Jenkins, et le troisième est l'application liée à l'âge.
Et votre rôle consiste essentiellement à donner aux utilisateurs l'accès aux trois services.
Supposons donc que tous les utilisateurs, tous les 500 utilisateurs au sein de l'organisation doivent avoir accès à
l'ensemble de ces trois systèmes.
Maintenant, l'un des défis que nous verrons en premier est que vous devrez créer des utilisateurs individuels dans
chacun de ces trois systèmes.
Ainsi, dans l'une ou l'autre des listes, vous devrez créer un utilisateur IAM dans le système de gestion du VIH.
Encore une fois, vous devrez créer un utilisateur et ainsi de suite.
Supposons maintenant qu'un nouvel utilisateur a rejoint votre organisation ou qu'un nouvel utilisateur quitte votre organisation.
Donc, essentiellement, vous devrez vous connecter à ces trois applications pour ajouter ou supprimer des utilisateurs.
Supposons maintenant que deux nouvelles applications arrivent dans l'organisation.
Donc, essentiellement, encore une fois, vous devrez ajouter tous les 500 utilisateurs aux deux nouveaux systèmes à venir qui sont en cours de
planification.
Ce n'est donc pas vraiment une façon très efficace de faire les choses.
C'est donc l'un des défis auxquels vous serez vraiment confronté dans une organisation de moyenne à grande échelle.
Plus précisément, lorsque vous discutez d'organisations à grande échelle qui comptent des
milliers d'utilisateurs, la gestion des utilisateurs sur chaque système n'est pas recommandée, ainsi que l'identité.
Donc, pour surmonter cela, le système est essentiellement utilisé pour stocker le centre de l'utilisateur.
Alors disons que vous avez un système.
Ainsi, dans cette ancienne application, toutes les identités des utilisateurs sont stockées.
Ainsi, tous les noms d'utilisateur et tous les mots de passe sont stockés dans ce répertoire central.
Et ce répertoire unique est connecté à tous les systèmes de manière à ce que les utilisateurs du centre puissent directement se
connecter avec le nom d'utilisateur et le mot de passe à l'ensemble de ces trois systèmes.
Cela devient donc une architecture beaucoup plus efficace car il n'y aura qu'un seul ensemble de nom d'utilisateur
et de mot de passe qui sera stocké au niveau final et à partir de la fin.
Puisqu'il y aura une confiance entre tous ces systèmes, l'utilisateur pourra facilement se connecter.
Ainsi, chaque fois qu'un nouvel utilisateur rejoint l'organisation, tout ce que l'administrateur doit faire, il doit ajouter son utilisateur dans
le cadre de l'ancienne application, et c'est à peu près tout.
Sera en mesure de se connecter à l'ensemble de ces trois systèmes et peut-être demain un nouveau système est prévu d'être
ajouté dans votre organisation.
Tout ce que vous aurez à faire est de faire confiance entre votre ancienne application et ce nouveau système et
tous les utilisateurs existants pourront également se connecter aux nouveaux systèmes.
Maintenant, il existe de nombreuses solutions qui nous permettent de stocker l'utilisateur de manière centralisée.
L'un des principaux que vous avez peut-être entendus est Microsoft Active Directory.
C'est une solution très populaire qui vous permet de stocker le centre utilisateur et vous permet également d'avoir
une gestion ordonnée.
Le deuxième populaire spécifiquement pour Linux est Red Hat Identity Management, également appelé application
gratuite.
Donc, si vous regardez la capture d'écran, celle-ci est associée à Active Directory et vous voyez qu'il
y a plusieurs utilisateurs qui ont été ajoutés ici et l'édition de la commande de l'utilisateur est très simple.
Vous voyez que vous pouvez cliquer sur Nouveau et vous pouvez cliquer sur l'utilisateur et un nouvel utilisateur sera ajouté à votre Active Directory.
Alors maintenant, disons que vous avez Active Directory et que vous avez ces trois systèmes.
Ce que vous devez faire, vous devez soit faire confiance entre votre Active Directory et ces trois systèmes
de manière à ce que les utilisateurs qui font partie de votre Active Directory puissent se connecter à l'ensemble de ces
trois systèmes en fonction de la politique qui vous avez défini.
Génial.
Donc, avec cela, allons de l'avant et comprenons les bases de la fédération d'un point de vue idéaliste.
Donc, fondamentalement, la fédération permet aux identités externes également appelées utilisateurs fédérés d'avoir un compte
Eatables interne à accès sécurisé sans avoir à en créer d'utilisateurs.
Nous avons donc déjà discuté du fait que les identités ne sont pas stockées dans un endroit,
elles sont stockées dans un serveur central comme Active Directory et tous ces utilisateurs pourront se connecter à votre compte.
C'est donc ce que le concept de Fédération entre vraiment en jeu.
Ainsi, ces identités externes peuvent provenir de diverses sources, comme le fournisseur d'identité d'entreprise peut être
Active Directory IPA, fournisseur d'identité Web.
Facebook.
Google.
Amazone.
Incognito ou ouvert, selon le cas d'utilisation que vous souhaitez réaliser.
Examinons maintenant rapidement le flux de travail de haut niveau lorsque nous discutons de la Fédération.
Il y a donc trois entités principales qui sont impliquées.
Le premier est l'utilisateur.
Le deuxième est le fournisseur de services et le troisième est le fournisseur d'identité.
Aucun fournisseur de services n'est fondamentalement ces applications de droite dont nous parlions, comme Jenkins EAW est un
système de gestion de données, etc.
En outre, ce sont les fournisseurs qui fournissent certains services.
Ensuite, vous avez un fournisseur d'identité à partir du nom lui-même.
Nous pouvons identifier ce que cela fait exactement.
Cela donne une identité.
Cela signifie donc essentiellement que les utilisateurs sont stockés au niveau du fournisseur d'identité et qu'il existe une relation
de confiance entre le fournisseur de services et le fournisseur d'identité.
Ainsi, ce fournisseur de services fait confiance au fournisseur d'identité et, par conséquent, les utilisateurs provenant de
ce fournisseur d'identité pourront se connecter au fournisseur de services en fonction des politiques que vous avez
définies.
Très bien.
Donc, si vous regardez dans le diagramme, l'utilisateur s'authentifie d'abord auprès du fournisseur d'identité.
Il ne s'authentifie pas auprès d'un fournisseur de services.
Donc, cela signifie essentiellement que disons que ce flux de travail est celui d'EWR.
C'est donc un fournisseur de services et il existe un fournisseur d'identité comme Okta.
Ainsi, les utilisateurs seront stockés au niveau d'octane.
Les utilisateurs ne seront pas stockés au niveau de la base de données.
Ainsi, l'utilisateur s'authentifiera d'abord auprès du fournisseur d'identité.
Maintenant, puisqu'il existe une relation, une relation de confiance entre l'IDP et le
fournisseur de services, l'utilisateur, une fois qu'il s'est authentifié avec succès auprès du fournisseur d'identité, il pourra
faire une demande réussie au fournisseur de services d'EWR.
Alors avec ça, allons-y et comprenons rapidement les choses plus en détail.
Le premier concept important ici est le courtier d'identité.
Le courtier d'identité est donc un service intermédiaire qui connecte ici plusieurs fournisseurs.
Donc sous identité, vous avez un idlis.
Sur le côté gauche, vous avez un Active Directory qui contient tous les noms d'utilisateur et mots de
passe de tous les employés de votre organisation.
Alors, qu'est-ce que vous voulez?
Vous voulez intimider un service qui peut connecter les deux.
C'est donc ce qu'on appelle le courtier d'identité.
Alors allons-y et regardons la vidéo de travail.
Sur le côté droit, vous avez la place, sur le côté gauche, vous avez l'Active Directory et
pourtant en place.
Ainsi, les utilisateurs devront d'abord se connecter au courtier d'identité.
Ce courtier d'identité est donc connecté à Microsoft Active Directory.
Donc, fondamentalement, quel nom d'utilisateur et mot de passe l'utilisateur fourni au courtier d'identité correspond-il à celui qui
est stocké dans Active Directory ?
C'est donc là que l'authentification a vraiment lieu.
La première étape est la connexion.
La deuxième étape consiste à authentifier l'utilisateur avec l'Active Directory.
Une fois l'authentification réussie, ce courtier d'identité continuera et appellera le service A spear
et il recevra un jeton spécifique, puis le courtier d'identité renverra la réponse appropriée au
client.
Et ce jeton est ce qui a de nouveau été utilisé pour se connecter aux services Web d'Amazon.
Ainsi, lorsque nous discutons de cet auteur, celui-ci est symbolique.
Ce n'est rien d'autre qu'un ensemble de clés d'accès et secrètes.
Ainsi, les clés d'accès et secrètes sont fournies aux utilisateurs, et les utilisateurs peuvent utiliser ces clés secrètes d'accès pour
se connecter à l'EWG.
C'est donc le flux de travail de haut niveau sur la façon dont les choses fonctionneraient d'un point de vue fédéré, je pense.
Alors allons-y et révisons rapidement les étapes.
Le premier est que les utilisateurs se connectent avec le nom d'utilisateur et le mot de passe, et ces informations d'identification sont
données au courtier d'identité.
Désormais, Identity Broker valide ces informations d'identification par rapport à Active Directory.
Dans cet exemple, nous avons pris Active Directory.
Si les informations d'identification sont valides.
Fondamentalement, si le nom d'utilisateur et le mot de passe sont valides, le courtier contactera le service SDR car cela
ira de l'avant et rendra la sécurité d'accès.
Et cette clé secrète d'accès sera fournie par le courtier d'identité à l'utilisateur et l'utilisateur pourra se connecter à la
console de base de données ou en toute sécurité en utilisant cet ensemble de clé secrète d'accès avec le jeton
spécifique, qui a une durée spécifique.
Donc, si vous ne vous souvenez pas quand nous discutons des identités, des identités, rien que des utilisateurs.
Ainsi, lorsque nous discutons de nos identités externes, cela signifie essentiellement que les utilisateurs sont stockés dans
un système externe, pas dans IEM.
Deuxièmement, le courtier d'identité, qui est essentiellement un middleware qui emmène l'utilisateur du point de départ et l'aide à se
connecter au point B.
Et le troisième concept important est l'identité stockée, qui est essentiellement un endroit où se trouvent les utilisateurs, mais où
les autres utilisateurs sont stockés.
Donc Active Directory ou IP ou peut-être Facebook.
Il s'agit donc essentiellement de l'identité stockée.
Maintenant, avant de conclure, des choses très importantes que je voulais partager.
Premièrement, pour que la Fédération fonctionne, ce fournisseur de services devrait également prendre en charge cette fonctionnalité, car
nous en avons finalement discuté.
Le fournisseur d'identité stockera les identités et il y aura une relation de confiance entre l'identité fournie et celle
du fournisseur de services.
Maintenant, si le fournisseur de services ne prend pas vraiment en charge cette fonctionnalité, vous ne pouvez pas vraiment
avoir de fédération.
C'est donc une partie importante à retenir.
Maintenant, lorsque nous discutons d'Idlis, lorsque vous accédez à la console IAM, vous avez une option spécifique de
celle du fournisseur d'identité.
C'est donc là que vous pouvez aller de l'avant et ajouter plusieurs fournisseurs d'identité.
Donc menu identité Gordon fourni vous devrez essentiellement spécifier un type de fournisseur ainsi que le document de métadonnées
de celui de votre fournisseur d'identité.
Ainsi, par exemple, disons que vous avez choisi le fournisseur d'identité d'OCTA.
OCTA est donc une plate-forme de fournisseur d'identité très populaire.
Donc, ce document de métadonnées dont nous parlions vient de l'OCTA.
Ainsi, après avoir configuré les paramètres de demande dans OCTA, vous pouvez continuer et télécharger ce
document de métadonnées après l'avoir téléchargé depuis OCTA.
Et c'est ainsi que lors d'un audit de haut niveau, la confiance s'établit réellement entre un fournisseur de services
et celui du fournisseur d'identité.
C'est donc une partie.
Deuxième chose dont nous parlions également, prenons un exemple de Jenkins.
Passons rapidement au Manager Jenkins et configurons la sécurité globale.
Donc, fondamentalement, ce dont nous discutons dans ces comptes sur la façon dont les données de l'utilisateur sont stockées de manière
centralisée dans un laboratoire, devrait pouvoir se connecter à une application spécifique comme Jenkins.
Maintenant, si Jenkins ne publie pas ou ne remet pas cela en place, tout ce concept ne fonctionnera pas vraiment.
Jenkins devra donc également prendre en charge un point de vue spécifique à LDAP.
Donc, si vous allez dans les paramètres Jenkins sous URI, vous avez essentiellement deux options importantes.
Le premier est la propre base de données d'utilisateurs de Jenkins.
Cela signifie donc essentiellement que chaque fois que vous ajoutez un utilisateur, vous l'ajoutez à la base de données Jenkins et vous avez également
la possibilité de permettre à l'utilisateur de dire, non, c'en est un.
Voyons maintenant, comme nous en discutons, vous ne voulez pas vraiment créer l'utilisateur individuellement dans un système
individuel.
Qu'est-ce que vous voulez?
Vous voulez finir ?
Vous avez donc également une option pour un tableau de bord ici, et à l'intérieur de celui-ci, vous devrez fournir les détails du mot de
fin d'épisode.
Ainsi, une fois que vous avez ce serveur, vous fournissez les détails à celui de Jenkins, et une fois que
vous avez la configuration nécessaire, les utilisateurs qui font partie d'un LDAP pourront se connecter à Jenkins audio.
À droite.
C'est donc la vue d'ensemble de haut niveau.
Si c'est quelque chose qui vous intéresse vraiment, alors Okta est une plate-forme populaire que vous pouvez
essayer.
Ils ont également plusieurs certifications associées, qui sont assez bonnes.
C'est donc quelque chose que vous pouvez vous attendre à faire.
Voilà donc la vue d'ensemble de haut niveau sur la Fédération.
Et avec cela se terminera la vidéo d'aujourd'hui.