Pour le moment, nous avons vu que, pour accéder à un compte AWS, il fallait au préalable qu’un admin nous crée un utilisateur IAM (user). Cela fonctionne bien lorsque le nombre d'usagers reste raisonnable, c’est-à-dire une dizaine. C’était le cas de The Green Earth Post au début, mais aujourd’hui l’équipe du journal comprend déjà 65 personnes et elle continue à grandir rapidement. C’est aussi à vous, l’architecte de solutions, d’assurer que ça se passe bien.
Alors, qu’est-ce qui se passe dans le cadre d’une grande entreprise ?
En effet, dans ce cas le nombre d’employés à devoir accéder directement à un compte AWS ou à des applications hébergées par AWS est très grand, des centaines voire des milliers. Heureusement pour nous, ces entreprises possèdent des dispositifs centralisés pour gérer l’ajout et la suppression d’utilisateurs, ainsi que leur mode d’authentification et d’autorisation.
Ce matin, vous vous connectez à votre boîte mail pour recevoir le message suivant de Thor :
Hello !
Je viens de discuter avec nos partenaires, l’équipe de data science qui met en place des systèmes de recommandation à partir des commentaires dans notre nouveau site. Ils ont besoin d'accès à nos bases de données, est-ce que tu peux leur donner l'autorisation ?
Merci !
Dans ce cas, on s'appuierait sur une authentification à partir de l’Active Directory du partenaire. De plus, il serait aussi envisageable d’ajouter un système d’authentification sur le site web pour fidéliser les lecteurs, en s’appuyant sur leur compte Gmail ou Facebook.
Authentifiez et autorisez des utilisateurs externes à AWS
Faire confiance à un dispositif externe pour l’authentification, comme présenté en introduction, est le concept de fédération d'identité (identity federation). Le dispositif est désigné comme le tiers de confiance (third party) ou un fournisseur d’identité (identity provider - IdP). Le fonctionnement se décline comme suit :
Voici les étapes d’un accès avec un fournisseur d’identité :
L’admin établit une relation d’approbation (lien de confiance), c’est-à-dire qu’AWS délègue à un tiers de confiance la gestion des accès à des utilisateurs externes.
L’utilisateur externe se connecte au tiers de confiance.
Si la connexion réussit, le tiers de confiance envoie un jeton pour s’authentifier.
L’utilisateur envoie son jeton pour se connecter à AWS, qui vérifie avec le tiers de confiance que le jeton est valide. Si oui, l’accès est autorisé.
La fédération d’identité permet aux utilisateurs extérieurs à AWS d'assumer un rôle temporaire prédéfini pour accéder aux ressources AWS.
Regardons plus en détail ces variantes. Celle du Single Sign On aura une section dédiée car elle demande un peu plus de précisions… Vous êtes prêt ?
Variante #1 : SAML 2.0
SAML 2.0 est une norme ouverte utilisée par de nombreux fournisseurs d’identité. Une fédération d’identité avec cette norme permet de fournir une connexion temporaire à la console AWS ou à l’API AWS.
Voici un schéma explicatif de cette variante dans le cas d’un utilisateur souhaitant se connecter à un bucket S3 en ligne de commande (CLI).
Voici les étapes du process :
À l'aide d'une application cliente, un utilisateur demande son authentification par le fournisseur d’identité (idP) de l'organisation.
L’idP authentifie l'utilisateur.
L’idP crée une assertion SAML à l'aide des informations concernant l'utilisateur et l'envoie à l'application client.
L'application cliente appelle l’opération AssumeRoleWithSAML de l'API AWS STS, en transmettant l'assertion SAML.
La réponse de l'API renvoie des informations d'identification de sécurité temporaires associées à un rôle prédéfini.
L'application cliente utilise ces informations pour appeler les opérations d'API Amazon S3.
Voici un schéma expliquant, cette fois-ci, comment un utilisateur accède à la console AWS.
Quelle est la différence par rapport au schéma précédent ? 🤔
La différence se situe à l’étape 4, où le navigateur client est redirigé vers un point de terminaison d'authentification et non pas directement vers AWS STS.
L'Active Directory (AD) est un annuaire LDAP pour les systèmes d'exploitation Windows qui est très répandu en entreprise. Si AD FS (Active Directory Federated Service), le service de fédération AD, est compatible avec SAML 2.0, alors il est possible de le lier à un compte AWS comme dans l’image suivante :
Variante #2 : Broker d’identité personnalisé
Cette variante est à implanter uniquement si le fournisseur d’identité n’est pas compatible avec la norme SAML 2.0. Il faut alors que le broker d'identité dispose d'autorisations d'accès à l'API AWS STS pour récupérer des tokens en s’appuyant sur l’opération AssumeRole ou GetFederationToken.
Le fonctionnement est indiqué comme suit :
L'utilisateur se rend sur le portail de l'organisation ou sur une application, afin d'accéder à la console ou à l’API AWS. Sans token, le portail de l'organisation le redirige vers une authentification auprès du broker d’identité.
Le broker d’identité valide l’authentification de l’utilisateur, sinon il recevra un message d’erreur.
Le broker d’identité appelle l’API STS pour récupérer des informations d'identification (credentials) temporaires pour l’utilisateur, qui seront associées à un rôle IAM prédéfini.
L’utilisateur peut alors se connecter à la console AWS ou à l’API AWS à partir des informations d'identification temporaires tout en assumant le rôle associé. Le jeton sera valide pour une durée de 15 minutes à 1 heure, à la suite de quoi l’utilisateur devra répéter la procédure.
Variante #3a : Fédération d'identité sans Amazon Cognito
Dans le cas d’une application mobile ou web avec un grand nombre d'utilisateurs, optez pour la fédération d'identité web, ce qui évite de créer des utilisateurs IAM.
Les fournisseurs d'identité sont par exemple Login withAmazon, Facebook Login, Google Login, etc.
Voici le fonctionnement :
L'application appelle un idP pour authentifier l'utilisateur.
L’idP retourne un jeton d'identité web à l'application.
L'application invoque AWS STS, en passant le token via l’opération AssumeRoleWithWebIdentity.
AWS STS autorise l'application et lui attribue des informations d'identification temporaires d'accès à AWS, associées à un rôle IAM prédéfini.
L'application invoque DynamoDB et ne peut effectuer que les actions autorisées dans les politiques du rôle.
Variante #3b : Fédération d’identité avec Amazon Cognito
Intéressons-nous à Amazon Cognito, qui a la particularité d’avoir deux produits :
Cognito User Pools (CUP) permet de :
découpler la gestion des utilisateurs d’une application mobile ou web :
inscription, connexion ;
récupération du mot de passe en cas d’oubli ;
vérification de l’email ou du numéro de téléphone ;
authentification MFA ;
se connecter via des idP ;
produire des tokens JWT à fournir à des applications sécurisées par AWS API Gateway.
Cognito Identity Pools (Federated Identities) permet de :
transformer le jeton d’un idP externe en clé d’accès temporaire IAM tout en assumant un rôle prédéfini ;
accéder directement aux services AWS — par exemple, accéder à une vidéo stockée dans un compartiment S3 à partir d’une authentification via son compte CUP, Facebook ou Google (voir schéma ci-dessous).
Variante #4 – Accédez à des comptes et applications via l’authentification unique SSO d’AWS
SSO signifie l'authentification unique et vous permet d’accéder à une multitude de comptes et tiers de confiance en une seule authentification. AWS IAM Identity Center est le service managé qui implante ce principe. Il s’intègre avec AWS Organizations, tous les tiers de confiance supportant SAML 2.0 et les Active Directory on-premises.
Le schéma ci-dessous explique comment un utilisateur d’une organisation dont les informations d’identification sont contenues dans un AD On-Premises peut se connecter en même temps à des applications Cloud, à des comptes AWS et des applications SAML personnalisées. Le tout grâce à une authentification unique via AWS IAM Identity Center.
Pour The Green Earth Post, on pourra utiliser AWS IAM Identity Center pour configurer l’authentification et l’autorisation de chaque employé pour se connecter aux différents comptes AWS ainsi qu’aux applications hébergées dans le cloud AWS.
Questions types de l'examen
Voici quelques questions sur les sujets vus dans ce chapitre que vous pourriez avoir à l'examen. Essayez d'y réfléchir vous-même avant de vérifier les réponses.
Question 1
Un architecte de solutions doit concevoir une solution pour fournir une authentification unique au personnel existant dans une entreprise. Le personnel gère les applications web sur site et a également besoin d'accéder à la console de gestion AWS pour gérer les ressources dans le cloud AWS.
Quelle combinaison de services est la mieux adaptée pour répondre à ces exigences ?
Utiliser IAM et Amazon Cognito
Utiliser AWS Secure Token Service (STS) et SAML
Utiliser votre annuaire LDAP sur site avec IAM
Utiliser IAM et MFA
Question 2
Une application mobile télécharge des informations d'utilisation dans une base de données. Amazon Cognito est utilisé pour l'authentification, l'autorisation et la gestion des utilisateurs et la connexion des utilisateurs avec des identifiants Facebook.
Afin de stocker en toute sécurité les données dans DynamoDB, la conception doit utiliser des informations d'identification AWS temporaires. Quelle fonctionnalité d'Amazon Cognito est utilisée pour obtenir des informations d'identification temporaires pour accéder aux services AWS ?
Paires de clés
Groupes d’utilisateur
Groupes d’identité à avoir accès à DynamoDB
Fournisseurs d’identité SAML
En résumé
AWS permet la fédération d’identité. Un utilisateur externe peut s’authentifier et accéder à AWS en assumant un rôle prédéfini.
Il existe 4 variantes de fédération :
SAML 2.0
Broker d'identité personnalisé
Fédération d’identité web avec ou sans Amazon Cognito
Single Sign On (SSO)
Le système SSO d'authentification unique permet d’accéder à plusieurs comptes avec une seule authentification.
Il est géré par le service AWS IAM Identity Center (successeur d'AWS SSO) qui permet d’accéder avec une authentification unique à une multitude d’applications et de comptes AWS appartenant à la même organisation.
Après avoir vu comment mettre en place l’authentification centralisée d’utilisateurs et d’applications à AWS, nous allons découvrir comment un développeur peut, programmatiquement, interagir avec AWS.
