Octroyer l'accès à des utilisateurs authentifiés en externe (fédération d'identité)

Vos utilisateurs ont peut-être déjà une identité extérieure AWS, par exemple dans votre annuaire d'entreprise. Si ces utilisateurs ont besoin de travailler avec AWS des ressources (ou de travailler avec des applications qui accèdent à ces ressources), ils ont également besoin d'informations d'identification AWS de sécurité. A l'aide d'un rôle IAM, vous pouvez définir des autorisations pour des utilisateurs dont l'identité est fédérée par votre organisation ou un fournisseur d'identité (IdP) tiers.

Note

En tant que bonne pratique de sécurité, nous vous recommandons de gérer l'accès des utilisateurs dans IAM Identity Center à l'aide de la fédération d'identité plutôt que de créer des utilisateurs IAM. Pour en savoir plus sur les situations spécifiques dans lesquelles un utilisateur IAM est nécessaire, veuillez consulter Quand créer un utilisateur IAM (au lieu d'un rôle).

Fédération d'utilisateurs d'une application mobile ou web à l'aide d'Amazon Cognito

Si vous créez une application mobile ou Web qui accède aux AWS ressources, l'application a besoin d'informations d'identification de sécurité pour pouvoir envoyer des demandes programmatiques à. AWS Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons d'utiliser Amazon Cognito. Vous pouvez utiliser ce service avec le SDK AWS mobile pour iOS et AWS le SDK mobile pour Android et Fire OS afin de créer des identités uniques pour les utilisateurs et de les authentifier afin de sécuriser l'accès à vos ressources. AWS Amazon Cognito prend en charge les mêmes fournisseurs d'identité que ceux répertoriés dans la section suivante, ainsi que les identités authentifiées par le développeur et les accès non authentifiés (invité). Amazon Cognito fournit également des opérations d'API pour la synchronisation des données utilisateur afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour plus d’informations, veuillez consulter Utilisation d'Amazon Cognito pour les applications mobiles.

Fédération d'utilisateurs à l'aide de fournisseurs d'identité publics ou d'OpenID Connect

Dans la mesure du possible, utilisez Amazon Cognito pour les scénarios d'applications mobiles et Web. Amazon Cognito effectue la majeure partie du behind-the-scenes travail avec les services des fournisseurs d'identité publics pour vous. Il fonctionne avec les mêmes services tiers et prend également en charge les connexions anonymes. Toutefois, dans le cas de scénarios plus complexes, vous pouvez avoir directement recours à un service tiers tel que Login with Amazon, Facebook, Google, ou tout autre IdP compatible avec OpenID Connect (OIDC). Pour plus d'informations sur l'utilisation de la fédération OIDC à l'aide de l'un de ces services, consultezFédération OIDC.

Fédération d'utilisateurs avec SAML 2.0

Si votre organisation utilise déjà un progiciel de fournisseur d'identité compatible avec le SAML 2.0 (Security Assertion Markup Language 2.0), vous pouvez créer un climat de confiance entre votre organisation en tant que fournisseur d'identité (IdP) et en AWS tant que fournisseur de services. Vous pouvez ensuite utiliser SAML pour fournir à vos utilisateurs une authentification unique (SSO) fédérée AWS Management Console ou un accès fédéré aux opérations d'API d'appel. AWS Par exemple, si votre entreprise utilise Microsoft Active Directory et Active Directory Federation Services, vous pouvez utiliser la fédération à l'aide de SAML 2.0. Pour plus d'informations sur l'utilisation des utilisateurs fédérés avec SAML 2.0, consultez Fédération SAML 2.0.

Fédération d'utilisateurs via la création d'une application de broker d'identité personnalisé

Si votre base d'identités n'est pas compatible avec SAML 2.0, vous pouvez créer une application de broker d'identité personnalisé capable d'exécuter une fonction similaire. L'application broker authentifie les utilisateurs, leur demande des informations d'identification temporaires AWS, puis les fournit à l'utilisateur pour qu'il accède aux AWS ressources.

Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes qui accèdent aux AWS ressources de l'entreprise. Ils disposent déjà d'identités dans le système d'identité et d'authentification de l'entreprise et, par conséquent, Example Corp. ne souhaite pas créer un utilisateur IAM séparé pour chacun de ses employés.

Bob est développeur chez Example Corp. Pour permettre aux applications internes d'Example Corp. d'accéder aux AWS ressources de l'entreprise, Bob développe une application personnalisée de courtier d'identité. L'application vérifie que les employés sont connectés au système d'identité et d'authentification existant d'Example Corp., par exemple LDAP, Active Directory ou un autre système. L'application de broker d'identité obtient ensuite des informations d'identification de sécurité temporaires pour les employés. Ce scénario est similaire au précédent (une application mobile utilisant un système d'authentification personnalisé), sauf que les applications qui ont besoin d'accéder aux AWS ressources s'exécutent toutes sur le réseau de l'entreprise et que l'entreprise dispose d'un système d'authentification existant.

Pour obtenir les informations d'identification de sécurité temporaires, l'application de broker d'identité appelle AssumeRole ou GetFederationToken, selon la façon dont Bob veut gérer les politiques des utilisateurs et le délai d'expiration des informations d'identification. Pour plus d'informations sur les différences entre ces opérations d'API, consultez Informations d'identification de sécurité temporaires dans IAM et Contrôle des autorisations affectées aux informations d'identification de sécurité temporaires.) L'appel renvoie des informations de sécurité temporaires composées d'un identifiant de clé d' AWS accès, d'une clé d'accès secrète et d'un jeton de session. L'application de broker d'identité rend ensuite ces informations d'identification de sécurité temporaires accessibles à l'application interne de l'entreprise. L'application peut alors utiliser ces informations d'identification de sécurité temporaires pour appeler directement AWS . L'application met en cache les informations d'identification jusqu'à ce qu'elles parviennent à expiration, puis demande un nouvel ensemble d'informations d'identification temporaires. L'illustration suivante décrit ce scénario.

Ce scénario utilise les attributs suivants :

• L'application de broker d'identité dispose d'autorisations d'accès à l'API du service de jeton (STS) d'IAM pour créer des informations d'identification de sécurité temporaires.

• L'application de broker d'identité peut vérifier que les employés sont authentifiés dans le système d'authentification existant.

• Les utilisateurs peuvent obtenir une URL temporaire qui leur donne accès à la console de AWS gestion (appelée authentification unique).

Pour plus d'informations sur la création d'informations d'identification de sécurité temporaires, consultez Demande d'informations d'identification temporaires de sécurité. Pour plus d'informations sur l'accès des utilisateurs fédérés à la console AWS de gestion, consultezActivation de l'accès des utilisateurs fédérés SAML 2.0 à la AWS Management Console.