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.

Authentification des utilisateurs à l'aide d'un Application Load Balancer

Vous pouvez configurer un Application Load Balancer pour authentifier les utilisateurs de manière sécurisée à mesure qu'ils accèdent à vos applications. Cela vous permet de confier la tâche d'authentification des utilisateurs à votre équilibreur de charge pour que vos applications puissent se concentrer sur leur logique métier.

Préparation à l'utilisation d'un IdP compatible avec OIDC

Procédez comme suit si vous utilisez un fournisseur d'identité (IdP) compatible avec OIDC avec votre Application Load Balancer :

Préparer l'utilisation d'Amazon Cognito

Procédez comme suit si vous utilisez des groupes d'utilisateurs Amazon Cognito avec votre Application Load Balancer :

L'URL de rappel dans les paramètres du client de l'application doit contenir uniquement des lettres minuscules.

Pour permettre à un utilisateur de configurer un équilibreur de charge pour utiliser Amazon Cognito lors de l'authentification des utilisateurs, vous devez autoriser l'utilisateur à appeler l'action cognito-idp:DescribeUserPoolClient.

Préparez-vous à utiliser Amazon CloudFront

Activez les paramètres suivants si vous utilisez une CloudFront distribution devant votre Application Load Balancer :

Configuration de l'authentification utilisateur

Vous configurez l'authentification utilisateur en créant une action d'authentification pour une ou plusieurs règles d'écouteur. Les types d'action authenticate-cognito et authenticate-oidc sont pris en charge uniquement avec les écouteurs HTTPS. Pour obtenir une description des champs correspondants, reportez-vous à AuthenticateCognitoActionConfiget AuthenticateOidcActionConfigdans la version 2015-12-01 de référence de l'API Elastic Load Balancing.

L'équilibreur de charge envoie un cookie de session au client pour conserver l'état d'authentification. Ce cookie contient toujours l'attribut secure, car l'authentification utilisateur nécessite un écouteur HTTPS. Ce cookie contient l'attribut SameSite=None avec les demandes CORS (partage des ressources cross-origin).

Pour un équilibreur de charge prenant en charge plusieurs applications nécessitant une authentification client indépendante, chaque règle d'écouteur comportant une action d'authentification doit avoir un nom de cookie unique. Cela garantit que les clients sont toujours authentifiés auprès de l'IdP avant d'être routés vers le groupe cible spécifié dans la règle.

Les Application Load Balancers ne prennent pas en charge les valeurs de cookie codées par URL.

Par défaut, le champ SessionTimeout est défini sur 7 jours. Si vous souhaitez des sessions plus courtes, vous pouvez configurer un délai d'expiration d'1 seconde au minimum. Pour plus d’informations, consultez Délai d'expiration de session.

Définissez le champ OnUnauthenticatedRequest selon les besoins de votre application. Par exemple :

L'équilibreur de charge doit être en mesure de communiquer avec le point de terminaison de jeton de l'IdP (TokenEndpoint) et le point de terminaison d'infos utilisateur de l'IdP (UserInfoEndpoint). Les équilibreurs de charge d'application ne prennent en charge l'IPv4 que lorsqu'ils communiquent avec ces points de terminaison. Si votre IdP utilise des adresses publiques, assurez-vous que les groupes de sécurité de votre équilibreur de charge et les ACL réseau de votre VPC autorisent l'accès aux points de terminaison. Lorsque vous utilisez un équilibreur de charge interne ou le type d'adresse IPdualstack-without-public-ipv4, une passerelle NAT peut permettre à l'équilibreur de charge de communiquer avec les points de terminaison. Pour plus d'informations, consultez Principes de base des passerelles NAT dans le Guide de l'utilisateur Amazon VPC.

Utilisez la commande create-rule suivante pour configurer l'authentification utilisateur.

aws elbv2 create-rule --listener-arn listener-arn --priority 10 \
--conditions Field=path-pattern,Values="/login" --actions file://actions.json

Voici un exemple de fichier actions.json qui spécifie une action authenticate-oidc et une action forward. AuthenticationRequestExtraParams vous permet de transmettre des paramètres supplémentaires à un IdP lors de l'authentification. Veuillez suivre la documentation fournie par votre fournisseur d'identité pour déterminer les champs pris en charge

[{
    "Type": "authenticate-oidc",
    "AuthenticateOidcConfig": {
        "Issuer": "https://idp-issuer.com",
        "AuthorizationEndpoint": "https://authorization-endpoint.com",
        "TokenEndpoint": "https://token-endpoint.com",
        "UserInfoEndpoint": "https://user-info-endpoint.com",
        "ClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "ClientSecret": "123456789012345678901234567890",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

Voici un exemple de fichier actions.json qui spécifie une action authenticate-cognito et une action forward.

[{
    "Type": "authenticate-cognito",
    "AuthenticateCognitoConfig": {
        "UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id",
        "UserPoolClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "UserPoolDomain": "userPoolDomain1",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

Pour plus d’informations, consultez Règles d'un écouteur.

Flux d'authentification

Le schéma de réseau suivant est une représentation visuelle de la façon dont un Application Load Balancer utilise OIDC pour authentifier les utilisateurs.

Les éléments numérotés ci-dessous mettent en évidence et expliquent les éléments présentés dans le schéma de réseau précédent.

Chaque nouvelle demande passe par les étapes 1 à 11, tandis que les demandes suivantes passent par les étapes 9 à 11. C'est-à-dire que chaque demande suivante commence à l'étape 9 tant que le cookie n'a pas expiré.

Le cookie AWSALBAuthNonce est ajouté à l'en-tête de la demande une fois que l'utilisateur s'est authentifié auprès de l'IdP. Cela ne change pas la façon dont l'Application Load Balancer traite les demandes de redirection provenant de l'IdP.

Si l'IdP fournit un jeton d'actualisation valide dans le jeton d'identification, l'équilibreur de charge enregistre ce jeton et l'utilise pour actualiser les demandes utilisateur chaque fois que le jeton d'accès expire, jusqu'à ce que la session expire ou que l'actualisation de l'IdP échoue. Si l'utilisateur se déconnecte, l'actualisation échoue et l'équilibreur de charge redirige l'utilisateur vers le point de terminaison d'autorisation de l'IdP. Cela permet à l'équilibreur de charge de supprimer des sessions une fois que l'utilisateur s'est déconnecté. Pour plus d’informations, consultez Délai d'expiration de session.

Encodage de demandes utilisateur et vérification de signature

Une fois votre équilibreur de charge a authentifié un utilisateur avec succès, il envoie les demandes utilisateur reçues de l'IdP à la cible. L'équilibreur de charge signe les demandes utilisateur pour que les applications puissent vérifier la signature et s'assurer que les demandes ont été envoyées par l'équilibreur de charge.

Les jetons d'accès et les réclamations des utilisateurs sont différents des jetons d'identification. Les jetons d'accès et les réclamations des utilisateurs autorisent uniquement l'accès aux ressources du serveur, tandis que les jetons d'identification contiennent des informations supplémentaires pour authentifier un utilisateur. L'Application Load Balancer crée un nouveau jeton d'accès lors de l'authentification d'un utilisateur et transmet uniquement les jetons d'accès et les demandes au backend, mais il ne transmet pas les informations du jeton d'identification.

Ces jetons suivent le format JWT, mais ne sont pas des jetons d'identification. Le format JWT inclut un en-tête, une charge utile et une signature qui sont encodés en URL base64 et inclut des caractères de remplissage à la fin. Un Application Load Balancer utilise ES256 (ECDSA utilisant P-256 et SHA256) pour générer la signature JWT.

L'en-tête JWT est un objet JSON avec les champs suivants :

{
   "alg": "algorithm",
   "kid": "12345678-1234-1234-1234-123456789012",
   "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", 
   "iss": "url",
   "client": "client-id",
   "exp": "expiration"
}

La charge utile JWT est un objet JSON qui contient les demandes utilisateur reçues du point de terminaison d'infos utilisateur de l'IdP.

{
   "sub": "1234567890",
   "name": "name",
   "email": "alias@example.com",
   ...
}

Comme l'équilibreur de charge ne chiffre pas les demandes utilisateur, nous vous recommandons de configurer le groupe cible pour utiliser HTTPS. Si vous configurez votre groupe cible pour utiliser HTTP, veillez à restreindre le trafic vers votre équilibreur de charge à l'aide de groupes de sécurité.

Pour garantir la sécurité, vous devez vérifier la signature avant d'effectuer toute autorisation basée sur les revendications et vérifier que le signer champ de l'en-tête JWT contient l'ARN Application Load Balancer attendu.

Pour obtenir la clé publique, obtenez l'ID de clé de l'en-tête JWT et utilisez-le pour rechercher la clé publique à partir du point de terminaison. Le point de terminaison pour chaque région AWS est le suivant :

https://public-keys.auth.elb.region.amazonaws.com/key-id

En effet AWS GovCloud (US), les points de terminaison sont les suivants :

https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id
https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id

L'exemple suivant montre comment obtenir l'ID de la clé, la clé publique et la charge utile en Python 3.x :

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_jwt_headers = decoded_jwt_headers.decode("utf-8")
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

L'exemple suivant montre comment obtenir l'ID de la clé, la clé publique et la charge utile en Python 2.7 :

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

Expiration

Délai d'expiration de session

Le jeton d'actualisation et le délai d'expiration de session fonctionnent conjointement comme suit :

Délai d'expiration de connexion client

Un client doit lancer et terminer le processus d'authentification dans les 15 minutes. Si un client ne parvient pas à effectuer l'authentification dans le délai de 15 minutes, il reçoit une erreur HTTP 401 de la part de l'équilibreur de charge. Ce délai d'expiration ne peut pas être modifié ou supprimé.

Par exemple, si un utilisateur charge la page de connexion via l'Application Load Balancer, il doit terminer le processus de connexion dans les 15 minutes. Si l'utilisateur attend puis tente de se connecter après l'expiration du délai de 15 minutes, l'équilibreur de charge renvoie une erreur HTTP 401. L'utilisateur devra actualiser la page et essayer de se reconnecter.

Déconnexion de l'authentification

Lorsqu'une application doit déconnecter un utilisateur authentifié, elle doit définir le délai d'expiration du cookie de session d'authentification sur -1 et rediriger le client vers le point de terminaison de déconnexion de l'IdP (si l'IdP en prend un en charge). Pour empêcher les utilisateurs de réutiliser un cookie supprimé, nous vous recommandons de configurer un délai d'expiration aussi court que raisonnable pour le jeton d'accès. Si un client fournit à un équilibreur de charge un cookie de session comportant un jeton d'accès expiré avec un jeton d'actualisation non-NULL, l'équilibreur de charge prend contact avec l'IdP pour déterminer si l'utilisateur est toujours connecté.

La page d'accueil de déconnexion du client est une page non authentifiée. Cela signifie qu'elle ne peut pas être à l'origine d'une règle Application Load Balancer nécessitant une authentification.