Lorsqu'une entité tente d'assumer un rôle Resource Access Management (RAM), le service RAM évalue un ensemble de politiques pour déterminer s'il faut autoriser ou refuser la demande. Cette rubrique explique la logique d'évaluation qui s'applique spécifiquement à l'action sts:AssumeRole.
L'assomption d'un rôle RAM est une action particulière qui nécessite de vérifier simultanément deux ensembles d'autorisations :
Les autorisations de l'entité : l'entité (un utilisateur RAM ou un autre rôle) qui tente d'assumer le rôle doit disposer d'une politique basée sur l'identité lui accordant l'autorisation d'appeler l'action
sts:AssumeRolesur le rôle cible.La politique de confiance du rôle : le rôle assumé doit posséder une politique de confiance (une politique basée sur les ressources) qui définit le demandeur en tant qu'entité de confiance.
Ces deux conditions doivent être remplies pour que la requête aboutisse. Le processus d'évaluation est illustré ci-dessous.
L'évaluation des politiques lors de l'assomption d'un rôle RAM suit la logique standard, à une exception près : l'étape de combinaison des décisions (étape 4).
Si vous maîtrisez déjà le processus standard, il vous suffit de consulter l'étape 4 de cette rubrique. Pour obtenir une vue d'ensemble complète des règles standards, consultez la section Évaluation des politiques par le service RAM.
Étape 1 : Évaluer les politiques de contrôle Resource Directory (le cas échéant)
Si le compte fait partie d'un répertoire de ressources, le service RAM évalue les politiques de contrôle applicables. Ces politiques servent de garde-fous en matière d'autorisations pour le compte.
Si la politique de contrôle n'autorise pas l'action demandée, la requête est refusée et l'évaluation s'arrête.
Si l'action est autorisée, l'évaluation passe à l'étape suivante.
En l'absence de politiques de contrôle, cette étape est ignorée.
Les politiques de contrôle s'appliquent à toutes les entités RAM (utilisateurs et rôles) au sein d'un compte membre, mais ne concernent ni le propriétaire de ce compte, ni les entités du compte de gestion du répertoire de ressources.
Étape 2 : Évaluer les politiques de session du rôle RAM (le cas échéant)
Si l'entité est un rôle RAM assumé avec une politique de session (par exemple via l'opération AssumeRole), le service RAM évalue cette politique.
Si la politique de session n'autorise pas l'action demandée, la requête est refusée et l'évaluation s'arrête.
Si l'action est autorisée, l'évaluation se poursuit.
Cette étape est ignorée pour les requêtes émises par un utilisateur RAM et pour les connexions SSO fédérées, car les politiques de session ne s'appliquent pas dans ces contextes.
Étape 3 : Évaluer les politiques basées sur l'identité et les politiques basées sur les ressources
Le service RAM évalue les politiques basées sur l'identité (associées à l'utilisateur ou au rôle RAM demandeur) ainsi que les politiques basées sur les ressources (associées à la ressource cible).
-
Politique basée sur l'identité : le service RAM évalue toutes les politiques associées à l'entité demanderesse. Si une politique refuse explicitement la requête, le résultat est un refus explicite. Si au moins une politique autorise la requête, le résultat est une autorisation. Dans les autres cas, le résultat est un refus implicite.
RemarqueLors d'une connexion SSO initiée par un fournisseur d'identité (IdP), l'utilisateur n'a pas encore endossé d'identité ; aucune politique basée sur l'identité n'est donc évaluée. Seule la politique de confiance du rôle RAM est vérifiée.
Politique basée sur les ressources : si la ressource cible possède une politique basée sur les ressources (telle qu'une politique de compartiment OSS ou une politique de confiance de rôle RAM), le service RAM l'évalue selon la même logique : le résultat est soit une autorisation, soit un refus explicite, soit un refus implicite. En l'absence de politique basée sur les ressources, cette vérification est ignorée.
Étape 4 : Combiner les décisions et déterminer le résultat final
Enfin, le service RAM combine les résultats de l'étape 3 pour prendre une décision finale. La logique appliquée à l'assomption d'un rôle est plus stricte que celle utilisée pour les autres actions :
La requête est AUTORISÉE uniquement si la politique basée sur l'identité ET la politique de confiance du rôle RAM aboutissent toutes deux à une décision
Allow.Dans tous les autres cas, y compris si l'une ou l'autre des politiques entraîne un refus implicite ou explicite, la requête est REFUSÉE.