Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accès aux utilisateurs authentifiés en externe (fédération d’identité)

Il se peut que vos utilisateurs aient déjà des identités en dehors d'AWS, par exemple, dans un répertoire d'entreprise. Si ces utilisateurs doivent se servir de ressources AWS (ou travailler avec des applications qui accèdent à ces ressources), alors ces utilisateurs doivent également disposer d'informations d'identification de sécurité AWS. 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.

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 à des ressources AWS, celle-ci doit disposer d'informations d'identification de sécurité pour pouvoir effectuer des demandes par programmation à AWS. Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons d'utiliser Amazon Cognito. Vous pouvez utiliser ce service avec l'outil AWS Mobile SDK pour iOS et l'outil AWS Mobile SDK pour Android et Fire OS pour créer des identités uniques pour les utilisateurs et les authentifier pour un accès sécurisé à 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 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 pour vous la plupart des tâches en coulisses avec les services de fournisseur d'identité publique. 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 avec l’un de ces services, consultez Fédération OIDC.

Fédération d'utilisateurs avec SAML 2.0

Si l'organisation utilise déjà un logiciel de fournisseur d'identité prenant en charge SAML 2.0 (Security Assertion Markup Language 2.0), vous pouvez créer une relation d'approbation entre l'organisation, en tant que fournisseur d'identité (IdP), et AWS en tant que fournisseur de services. Il est ensuite possible d'utiliser SAML pour fournir aux utilisateurs une connexion avec authentification unique (SSO) fédérée à l’outil AWS Management Console ou un accès fédéré permettant d'appeler les opérations d'API 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 SAMLfédération 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. Le broker authentifie les utilisateurs, demande des informations d'authentification temporaires pour ceux-ci à partir de l’interface AWS, puis leur fournit ces informations d'identification pour leur permettre d'accéder aux ressources AWS.

Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes qui accèdent aux ressources AWS 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 ressources AWS de l'entreprise, il développe une application de broker d'identité personnalisé. 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 qui utilise un système d'authentification personnalisé), hormis le fait que toutes les applications qui doivent accéder aux ressources AWS s'exécutent au sein d'un réseau d'entreprise et que l'entreprise dispose déjà d'un système d'authentification.

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 Autorisations affectées aux informations d’identification de sécurité temporaires.) L'appel retourne des informations d'identification de sécurité temporaires constituées d'un ID de clé d'accès AWS, 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 :

Pour plus d'informations sur la création d'informations d'identification de sécurité temporaires, consultez Comparaison des informations d’identification AWS STS. Pour plus d'informations sur l'accès des utilisateurs fédérés à AWS Management Console, veuillez consulter Activation de l'accès des utilisateurs fédérés SAML 2.0 à la AWS Management Console.