Scénarios courants - AWS Identity and Access Management

Scénarios courants

Note

Nous vous recommandons de demander à vos utilisateurs humains d'utiliser des informations d'identification temporaires lors de l'accès à AWS. Avez-vous envisagé d'utiliser AWS IAM Identity Center ? Vous pouvez utiliser IAM Identity Center pour gérer de manière centralisée et depuis un seul endroit l'accès à plusieurs Comptes AWS et offrir aux utilisateurs un accès par authentification unique protégé par MFA à tous les comptes attribués. Avec IAM Identity Center, vous pouvez créer et gérer les identités des utilisateurs dans IAM Identity Center ou vous connecter facilement à votre fournisseur d'identité compatible SAML 2.0 existant. Pour plus d'informations, consultez Qu'est-ce que IAM Identity Center ? dans le Guide de l'utilisateur AWS IAM Identity Center.

Vous pouvez utiliser un fournisseur d’identité (IdP) externe pour gérer les identités des utilisateurs à l’extérieur d’AWS et de l’IdP externe. Un IdP externe peut fournir des informations d'identité à AWS en utilisant OpenID Connect (OIDC) ou Security Assertion Markup Language (SAML). L’OIDC est couramment utilisé lorsqu’une application qui ne fonctionne pas sur AWS a besoin d’accéder à des ressources AWS.

Lorsque vous souhaitez configurer une fédération avec un IdP externe, vous créez un fournisseur d'identité IAM pour informer AWS de l'IdP externe et sa configuration. Cela établit une relation de confiance entre votre Compte AWS et l’IdP externe. Les rubriques suivantes présentent des scénarios courants d’utilisation des fournisseurs d’identité IAM.

Amazon Cognito pour les applications mobiles

Le meilleur moyen d’utiliser la fédération OIDC consiste à utiliser Amazon Cognito. Par exemple, la développeuse Adèle est en train de créer un jeu pour appareil mobile dans lequel les données utilisateur, telles que les scores et les profils, sont stockées dans Amazon S3 et Amazon DynamoDB. Adèle pourrait également stocker ces données en local sur l'appareil et utiliser Amazon Cognito pour les maintenir synchronisées sur les différents appareils. Elle sait que pour des raisons de sécurité et de maintenance, des informations d'identification (credentials) de sécurité AWS à long terme ne doivent pas être distribuées avec le jeu. Elle sait également que le jeu pourrait avoir un grand nombre d'utilisateurs. Pour toutes ces raisons, elle ne veut pas créer de nouvelles identités dans IAM pour chaque joueur. Au lieu de cela, elle développe le jeu de sorte que les utilisateurs puissent se connecter à l’aide d’une identité qu’ils ont déjà établie avec un fournisseur d’identité (IdP) externe connu, comme Login with Amazon, Facebook, Google, ou tout fournisseur d’identité compatible OpenID Connect (OIDC). Son jeu peut tirer parti du mécanisme d'authentification de l'un de ces fournisseurs afin de valider l'identité de l'utilisateur.

Pour permettre à l'application mobile d'accéder à ses ressources AWS, Adèle s'enregistre d'abord pour un ID de développeur auprès du fournisseur d'identités qu'elle a choisi. Elle configure également l'application avec chacun de ces fournisseurs. Dans son Compte AWS qui contient le compartiment Amazon S3 et la table DynamoDB pour le jeu, Adèle utilise Amazon Cognito pour créer des rôles IAM qui définissent précisément les autorisations dont le jeu a besoin. Si elle utilise un IdP OIDC, elle crée également une entité IAM OIDC identity provider pour établir la confiance entre un groupe d'identité Amazon Cognito dans son Compte AWS et l'IdP.

Dans le code de l'application, Adèle appelle l'interface de la connexion pour le fournisseur d'identité l'IdP qu'elle a configuré précédemment. Le fournisseur d'identité traite tous les détails permettant à l'utilisateur de se connecter, et l'application obtient un jeton d'accès OAuth ou jeton d'ID OIDC du fournisseur. L'application d'Adèle peut échanger ces informations d'authentification contre un ensemble d'informations d'identification de sécurité temporaires qui se composent 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 peut ensuite utiliser ces informations d'identification pour accéder aux services web proposés par AWS. L'application est limitée aux autorisations qui sont définies dans le rôle qu'elle endosse.

La figure suivante illustre un flux simplifié d'un fonctionnement possible, à l'aide de Login with Amazon comme fournisseur d'identité. Pour l'étape 2, l'application peut également utiliser Facebook, Google ou tout fournisseur d'identité OIDC compatible, mais ce n'est pas présenté ici.

Exemple de flux de travail Amazon Cognito pour fédérer des utilisateurs pour une application mobile

  1. Un client démarre votre application sur un appareil mobile. L'application demande à l'utilisateur de se connecter.

  2. L'application utilise des ressources Login with Amazon pour accepter les informations d'identification de l'utilisateur.

  3. L'application utilise des opérations d'API Amazon Cognito GetId et GetCredentialsForIdentity pour échanger le jeton d'ID Login with Amazon (Connexion avec Amazon) contre un jeton Amazon Cognito. Amazon Cognito, qui a été configuré pour approuver votre projet Login with Amazon (Connexion avec Amazon), génère un jeton qu'il échange contre des informations d'identification de session temporaires avec AWS STS.

  4. L'application reçoit des informations d'identification de sécurité temporaires d'Amazon Cognito. Votre application peut également utiliser le flux de travail Basic (Classic) d'Amazon Cognito pour récupérer des jetons depuis AWS STS en utilisant AssumeRoleWithWebIdentity. Pour plus d'informations, consultez la rubrique Flux d'authentification des groupes d'identités (identités fédérées) dans le Guide du développeur Amazon Cognito.

  5. Les informations d'identification de sécurité temporaires peuvent être utilisées par l'application pour accéder aux ressources AWS requises par l'application pour fonctionner. Le rôle associé aux informations d'identification de sécurité temporaires et les politiques qui lui sont attribuées détermine ce qui est accessible.

Utilisez la procédure suivante afin de configurer votre application pour utiliser Amazon Cognito afin d'authentifier les utilisateurs et de donner à votre application un accès aux ressources AWS. Pour les étapes spécifiques permettant de réaliser ce scénario, consultez la documentation d'Amazon Cognito.

  1. (Facultatif) Connectez-vous en tant que développeur auprès de Login with Amazon, Facebook, Google ou tout autre fournisseur d'identité compatible OpenID Connect (OIDC) et configurez une ou plusieurs applications avec le fournisseur. Cette étape est facultative, car Amazon Cognito prend également en charge l'accès non authentifié (invité) pour vos utilisateurs.

  2. Accédez à Amazon Cognito dans la AWS Management Console. Utilisez l'assistant Amazon Cognito pour créer un groupe d'identités, qui est un conteneur utilisé par Amazon Cognito pour maintenir des identités d'utilisateur final organisées pour vos applications. Vous pouvez partager des pools d'identité entre des applications. Lorsque vous configurez un groupe d'identités, Amazon Cognito crée un ou deux rôles IAM (un pour les identités authentifiées et un pour les identités « invitées » non authentifiées) qui définissent des autorisations pour les utilisateurs d'Amazon Cognito.

  3. Intégrez AWSAmplify avec votre application et importez les fichiers requis pour utiliser Amazon Cognito.

  4. Créez une instance du fournisseur d'informations d'identification Amazon Cognito en transmettant l'ID de groupe d'identité, votre numéro d'Compte AWS et l'Amazon Resource Name (ARN) des rôles que vous avez associés au groupe d'identités. L'assistant Amazon Cognito dans AWS Management Console fournit des exemples de code pour vous aider à démarrer.

  5. Lorsque votre application accède à une ressource AWS, transmettez l'instance de fournisseur d'informations d'identification à l'objet client, qui transmet les informations d'identification de sécurité temporaires au client. Les autorisations pour les informations d'identification sont basées sur le ou les rôles que vous avez définis précédemment.

Pour plus d’informations, consultez les ressources suivantes :

Fédération OIDC pour applications mobiles

Vous obtiendrez les meilleurs résultats en utilisant Amazon Cognito comme fournisseur d’identité dans la quasi-totalité des scénarios de fédération OIDC. Amazon Cognito est facile à utiliser et offre des capacités supplémentaires, comme l'accès anonyme (sans authentification) et la synchronisation des données utilisateur entre les périphériques et les fournisseurs. Cependant, si vous avez déjà créé une application exploitant la fédération OIDC en appelant manuellement l’API AssumeRoleWithWebIdentity, vous pouvez continuer à l’utiliser : vos applications fonctionneront malgré tout.

L’utilisation de la fédération OIDC sans Amazon Cognito se déroule comme suit :

  1. Inscrivez-vous en tant que développeur auprès de l'IdP externe et configurez votre application avec l'ID unique qu'il vous donnera. (Dans ce processus, la terminologie varie selon les IdP. Ici, c'est le terme configurer qui est utilisé pour désigner le processus d'identification de votre application auprès de l'IdP.) Chaque IdP vous donne un ID d'application qui est unique à l'IdP. Ainsi, si vous configurez l'application auprès de plusieurs IdP, elle sera dotée de plusieurs ID d'application. Vous pouvez configurer plusieurs applications auprès de chaque fournisseur.

    Les liens externes suivants fournissent des informations sur quelques uns des fournisseurs d'identité (IdP) les plus utilisés :

    Important

    Si vous utilisez un fournisseur d'identité OIDC de Google, Facebook ou Amazon Cognito, ne créez pas de fournisseur d'identité IAM distinct dans la AWS Management Console. Ces fournisseurs d'identité OIDC sont intégrés à AWS et immédiatement disponibles. Ignorez l'étape suivante et passez directement à la création de rôles à l'aide de votre fournisseur d'identité.

  2. Si vous utilisez un IdP autre que Google, Facebook ou Amazon Cognito, compatible avec OIDC, créez une entité de fournisseur d'identité IAM pour lui.

  3. Dans IAM, créez un ou plusieurs rôles. Pour chaque rôle, définissez qui peut endosser le rôle (politique d'approbation) et les autorisations accordées aux utilisateurs de l'application (politique d'autorisation). En général, vous créez un rôle pour chaque IdP pris en charge par l'application. Par exemple, vous pouvez créer un rôle qui est endossé par une application si l'utilisateur se connecte via Login with Amazon, un deuxième rôle pour la même application s'il se connecte via Facebook, et un troisième rôle s'il se connecte via Google. Pour la relation d'approbation, spécifiez l'IdP (par exemple, Amazon.com) en tant que Principal (l'entité de confiance) et incluez un élément Condition qui correspond à l'ID d'application attribué par l'IdP. Des exemples de rôles pour différents fournisseurs sont présentés dans la rubrique Créer un rôle pour un fournisseur d’identité tiers .

  4. Dans votre application, authentifiez vos utilisateurs en recourant à l'IdP. La procédure à suivre varie en fonction de l'IdP utilisé (Login with Amazon, Facebook ou Google) et la plateforme sur laquelle s'exécute votre application. Par exemple, la méthode d'authentification d'une application Android peut être différente de celle d'une application iOS ou d'une application web JavaScript.

    En règle générale, si l'utilisateur n'est pas déjà connecté, l'IdP affiche une page de connexion. Une fois qu'il a authentifié l'utilisateur, l'IdP retourne un jeton d'authentification contenant des informations sur l'utilisateur à l'application. Ces informations dépendent de ce que l'IdP expose et des informations que l'utilisateur est disposé à partager. Vous pouvez utiliser ces informations dans votre application.

  5. Dans l'application, effectuez un appel non signé à l'action AssumeRoleWithWebIdentity pour solliciter des informations d'identification de sécurité temporaires. Dans la demande, vous transmettez le jeton d'authentification de l'IdP et spécifiez l'Amazon Resource Name (ARN) du rôle IAM que vous avez créé pour cet IdP. AWS vérifie que le jeton est approuvé et valide et, si c'est le cas, renvoie des informations d'identification de sécurité temporaires à votre application, avec notamment des autorisations pour le rôle que vous nommez dans la demande. La réponse inclut également des métadonnées se rapportant à l'utilisateur provenant de l'IdP telles que l'ID utilisateur unique que l'IdP associe à l'utilisateur.

  6. À l'aide des informations d'identification de sécurité temporaires contenues dans la réponse AssumeRoleWithWebIdentity, votre application envoie des demandes signées vers les opérations d'API AWS. Les informations d’identification de l’utilisateur provenant de l’IdP permettent de distinguer les utilisateurs de votre application. Par exemple, vous pouvez placer des objets dans des dossiers Amazon S3 qui incluent l’identifiant de l’utilisateur comme préfixe ou suffixe. Ceci vous permet de créer des politiques d'accès qui verrouillent un dossier, afin que seul l'utilisateur ayant l'ID approprié soit autorisé à y accéder. Pour de plus amples informations, consultez principaux d’utilisateur fédéré AWS STS.

  7. Votre application met généralement en cache ces informations d'identification de sécurité temporaires afin que vous n'ayez pas à en redemander à chaque fois que l'application doit envoyer une demande à AWS. Par défaut, les informations d'identification restent valides pendant une heure. Lorsque les informations d'identification expirent (ou avant le délai d'expiration), vous effectuez un autre appel à AssumeRoleWithWebIdentity pour obtenir un nouvel ensemble d'informations d'identification de sécurité temporaires. Selon l'IdP utilisé et la façon dont il gère ses jetons, il sera peut-être nécessaire d'actualiser le jeton de l'IdP avant un nouvel appel à AssumeRoleWithWebIdentity, car les jetons de l'IdP expirent généralement après un délai spécifié. Si vous utilisez le kit AWS SDK for iOS ou AWS SDK for Android, vous pouvez avoir recours à l'action AmazonSTSCredentialsProvider qui gère les informations d'identification temporaires IAM, en les actualisant si nécessaire.