Écoutez-vous et bienvenue dans la vidéo d'aujourd'hui, nous allons implémenter le compte croisé et la règle à partir
de zéro.
Maintenant, avant de faire cela, allons de l'avant et révisons rapidement l'architecture ici.
Donc, fondamentalement, vous devez vous contenter de ce qui vient en premier.
L'un est la valeur par défaut car l'identité a disparu.
Ainsi, le compte d'identité est l'endroit où les identités sont stockées et quelles identités, identités sont des utilisateurs IEM.
Et puis vous avez divers autres comptes où les ressources réelles sont excellentes.
Il peut s'agir d'un stablecoin.
Il peut être facile d'instances et ainsi de suite.
L'architecture est donc l'utilisateur IEM appartenant à ce compte d'identité.
Et puis, en fonction de l'autorisation de l'utilisateur, il peut se connecter au compte B, au compte C ou à tout
autre compte IWC présent via la fonctionnalité de rôle supposée.
Connaître les étapes globales qui sont impliquées sont les trois quarts.
La première est que vous devez créer un compte d'utilisateur, donc le compte n'est rien d'autre que le compte d'identité.
Ensuite, vous devez créer un rôle de compte fermé dans le compte B..
Ainsi, le contrôle croisé des comptes est l'endroit où vous allez de l'avant et créez le rôle IAM, et ce rôle IEM
est ce que les utilisateurs IEM du compte d'identité assumeront.
Et puis la troisième étape consiste à autoriser les utilisateurs à basculer vers les rôles du compte B, donc les données utilisateur IEM stockées
dans le compte d'identité.
Cet utilisateur a également besoin de l'autorisation d'assumer ce rôle, de sorte que l'autorisation que vous devrez donner dans le
compte d'identité.
Encore une fois, cela peut être un peu déroutant en ce moment.
Les Gordon ont implémenté à partir de zéro et cela deviendra alors très facile.
Donc, la première étape consiste à créer d'abord un compte utilisateur.
Maintenant, pour la démo d'aujourd'hui, j'ai deux comptes.
Le premier est le compte d'identité.
Donc, vous voyez, j'ai donné le nom à la base de données d'identité de l'appelant de cet onglet et au deuxième compte qui
s'exécute dans une seconde qui sera reflété en tant que compte B..
Donc, tout d'abord, comme vous le dites, la première étape consiste à créer l'utilisateur IEM dans le compte d'identité.
Faisons-le donc rapidement depuis l'IEEE.
Allons aux utilisateurs et créons un nouvel utilisateur.
Le nom a davantage mené cet appel et donnera à Eatables un accès au contrôle de gestion.
Définissons également rapidement le mot de passe pour l'utilisateur bulbe et nous supprimons la case à cocher associée à la création d'un nouveau mot
de passe lors de la signature et nous n'accorderons désormais aucune autorisation à l'utilisateur bulbe ici.
Puisqu'il s'agit d'une carte d'identité ?
Super.
D'accord, notre première étape est donc créée, donc notre utilisateur bob est créé dans l'icône d'identité.
La deuxième étape consiste à créer un contrôle dans le compte.
Pour être ainsi icône, nous allons créer un nouveau contrôle plus proche.
Passons donc au deuxième onglet et ici.
Ouvrons également le service IEM et à l'intérieur, allons de l'avant et ouvrirons les règles et créons une nouvelle
règle.
Maintenant, ici, vous avez plusieurs options.
L'un d'entre eux est un autre compte Eatables, alors allons-y et cliquez ici.
Et maintenant, ce que cela demande, c'est de demander le compte I. RÉ. Donc, cet ID de compte est l'endroit où vous
mettez l'idée de compte de l'icône d'identité.
Copiez donc l'idée du compte d'identité et collez-la une fois.
Alors faisons un suivant.
Et maintenant, il demande les autorisations.
Donc, cela signifie essentiellement qu'une fois que l'utilisateur IEM du compte d'identité assume ce rôle et se connecte au
compte B, quelles sont les autorisations que cet utilisateur doit avoir, s'il doit avoir accès à S3,
accès à easy to et ainsi de suite ?
Donc, ce que nous verrons, l'utilisateur devrait avoir accès, disons S3.
Je vais donc voir l'accès en lecture seule à S3, c'est parti.
Et ensuite, je vais faire une revue et le roulement, appelons ça comme compte de clôture B va de l'avant
et créer une grille pour que notre rôle soit créé.
Ouvrons cela rapidement.
Maintenant, vous voyez, pour le compte et le rôle croisés, vous avez essentiellement une option supplémentaire qui indique que ce lien
est donné à l'utilisateur qui peut changer de rôle dans la console.
Donc, si l'utilisateur bulb bob du compte d'identité souhaite se connecter au compte B, il doit alors
cliquer sur ce lien spécifique.
C'est donc une partie.
Cependant, avant de faire cela, complétons la troisième étape, qui permet à l'utilisateur de passer
au compte.
Donc, actuellement, ce qui s'est passé, c'est que notre utilisateur a créé un compte d'identité et cet utilisateur n'a
aucune autorisation.
Cela signifie donc que l'utilisateur bulbe ne pourra même pas aller de l'avant et se connecter au compte brut,
i. e. compte de rôle B.
Nous devons donc donner une autorisation minimale aux utilisateurs de bob afin qu'il puisse au moins se connecter au rôle
IEM des différents comptes Eatables.
C'est donc cette autorisation que nous allons donner dans cette troisième étape.
Revenons donc à notre premier onglet, cliquons sur.
Laws and Florida, utilisateur de Bob, allons de l'avant et créons une nouvelle politique, donc je vais soit dans la politique
intérieure, ouvrons Jason.
Permettez-moi de zoomer rapidement sur COVID-19.
Permettez-moi d'aller de l'avant et d'assembler la politique que j'ai déjà disponible.
Je collerai cette politique après cette vidéo afin que vous puissiez également l'essayer et dans l'action.
Il s'agit d'un rôle Zoom, ce qui signifie essentiellement que les utilisateurs de Bob devraient être en mesure d'assumer le rôle,
puis nous devons attribuer la zone et l'associé à la libération conditionnelle associée au compte.
Et dans la ressource que vous voyez, vous devez essentiellement indiquer la région de Raleigh.
Donc, à partir du compte, allons-y, copions ce rôle ici de toute façon, et allons de l'avant et soyons audio d'état.
Bob aussi.
Les utilisateurs pourront effectuer une opération Zoom roll sur ce compte croisé spécifique.
vont avoir honte.
Faisons une politique d'examen dans le nom.
Appelons-le comme voir un Zoom.
Tous vont être et nous allons créer une note politique.
Ainsi, nos trois étapes sont maintenant terminées.
Donc, la seule chose qui est nécessaire pour tester est de se connecter avec l'utilisateur bob dans
le compte d'identité, puis d'utiliser le lien qui nous a été fourni au niveau du compte b ira de l'avant et
verra comment Bob peut passer au compte B. Donc à partir du compte d'identité, revenons à leur tableau de bord afin que
nous puissions obtenir le lien de connexion.
Je vais rapidement dézoomer.
C'est donc le signe dans votre tête et à partir d'un nouvel onglet.
Allons de l'avant et ouvrons ça.
Je vais spécifier Bob et je vais également spécifier le mot de passe.
Super.
Donc, à ce stade, Bob est connecté au compte d'identité.
N'oubliez pas maintenant que vous ne devez donner aucune autorisation aux utilisateurs AM dans le compte d'identité.
Tout ce qu'ils devraient pouvoir faire, c'est effectuer des actions basées sur les comptes et les rôles.
Donc non du compte B. Copiez le lien de connexion et de notre musique Bob.
Allons de l'avant et collez strict.
Il vous demandera donc essentiellement le nom d'affichage.
Appelons simplement l'écran.
Les noms ont disparu.
Soyez et faisons un switcheroo.
Et maintenant, vous voyez que l'utilisateur bob est connecté au compte B. Maintenant, puisque Bob User a l'accès S3.
Vérifions rapidement s'il peut ouvrir ce service d'arborescence.
Et oui, il est capable de voir les trois consoles de la même manière.
Si vous examinez la règle des comptes croisés, le seul accès que nous avons donné était un trois en lecture seule.
Donc, si Bob essaie d'ouvrir la console facile, il devrait obtenir une erreur.
Et comme prévu, il a une erreur ici.
Aucun utilisateur de Steve Bob.
Supposons qu'il ait terminé son travail dans le compte b il peut revenir à son propre compte.
Donc, quand vous faites un dos à dos maintenant, ce qui se passera, c'est à partir de là que Bob reviendra
à l'icône d'identité.
Il s'agit donc essentiellement d'un compte d'identité ici.
Et même si le compte d'identité, il obtiendra cette erreur et de la même manière, lorsqu'il essaiera d'ouvrir le
S3 dans l'icône d'identité, il devrait de toute façon obtenir l'autorisation, disons ici aussi.
Et comme prévu, vous voyez que vous obtenez essentiellement un message d'autorisation refusée.
Super.
J'espère donc qu'avec cela, vous avez compris l'architecture de base d'un compte croisé et ce serait à nouveau, je vous encourage
vraiment à aller de l'avant et à l'essayer.
Ceci est très courant dans la plupart des organisations et dans les organisations qui n'ont pas vraiment mis en œuvre une
telle approche.
Vous êtes celui qui peut le faire.
Donc, avec cela, nous allons de l'avant et conclure la vidéo d'aujourd'hui.