Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Autenticación de usuarios mediante un Equilibrador de carga de aplicación

Puede configurar un Equilibrador de carga de aplicación para autenticar de forma segura a los usuarios cuando obtienen acceso a sus aplicaciones. Esto le permite liberar a su equilibrador de carga del trabajo de autenticación de usuarios para que sus aplicaciones puedan centrarse en su lógica de negocio.

Prepárese para usar un OIDC IdP compatible

Haga lo siguiente si utiliza un IdP OIDC compatible con su Application Load Balancer:

Preparación para usar Amazon Cognito

Haga lo siguiente si utiliza grupos de usuarios de Amazon Cognito con su Equilibrador de carga de aplicación:

La retrollamada de la configuración del cliente de la aplicación URL debe estar compuesta exclusivamente por letras minúsculas.

Para permitir que un usuario pueda configurar un equilibrador de carga para usar Amazon Cognito con el fin de autenticar a los usuarios, debe conceder al usuario el permiso para llamar a la acción cognito-idp:DescribeUserPoolClient.

Prepárate para usar Amazon CloudFront

Habilite los siguientes ajustes si utiliza una CloudFront distribución delante de su Application Load Balancer:

Configuración de la autenticación de usuarios

La autenticación de usuario se configura creando una acción de autenticación para una o varias reglas de oyente. Los tipos de authenticate-oidc acción authenticate-cognito y solo son compatibles con los oyentes. HTTPS Para obtener descripciones de los campos correspondientes, consulte AuthenticateCognitoActionConfigy AuthenticateOidcActionConfigen la versión 2015-12-01 de API referencia de Elastic Load Balancing.

El equilibrador de carga envía una cookie de sesión al cliente para mantener el estado de autenticación. Esta cookie siempre contiene el secure atributo, ya que la autenticación del usuario requiere un HTTPS agente de escucha. Esta cookie contiene el SameSite=None atributo con las solicitudes CORS (uso compartido de recursos entre orígenes).

En el caso de un equilibrador de carga compatible con varias aplicaciones que requieren una autenticación de cliente independiente, cada regla de oyente con una acción de autenticación debe tener un nombre de cookie único. Esto garantiza que los clientes estén siempre autenticados con el IdP antes de ser enrutados al grupo de destino especificado en la regla.

Los balanceadores de carga de aplicaciones no admiten valores de cookies codificadosURL.

De forma predeterminada, el campo SessionTimeout está configurado en 7 días. Si desea sesiones más cortas, puede configurar un tiempo de espera de sesión de tan solo 1 segundo. Para obtener más información, consulte Tiempo de espera de la sesión.

Establezca el campo OnUnauthenticatedRequest como apropiado para su aplicación. Por ejemplo:

El equilibrador de carga debe poder comunicarse con el punto de conexión de token de IdP (TokenEndpoint) y el punto de conexión de información de usuario de IdP (UserInfoEndpoint). Los balanceadores de carga de aplicaciones solo son compatibles IPv4 cuando se comunican con estos puntos finales. Si tu IdP usa direcciones públicas, asegúrate de que los grupos de seguridad del balanceador de cargas y la red ACLs de la que dispones VPC permitan el acceso a los puntos finales. Cuando se utiliza un balanceador de cargas interno o el tipo de dirección IPdualstack-without-public-ipv4, una NAT puerta de enlace puede permitir que el balanceador de cargas se comunique con los puntos finales. Para obtener más información, consulta los conceptos básicos de las puertas de NAT enlace en la Guía VPC del usuario de Amazon.

Utilice el siguiente comando create-rule para configurar la autenticación de usuario.

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

A continuación se muestra un ejemplo del archivo actions.json que especifica una acción authenticate-oidc y una acción forward. AuthenticationRequestExtraParams le permite pasar parámetros adicionales a un IdP durante la autenticación. Siga la documentación proporcionada por su proveedor de identidad para determinar los campos que son compatibles

[{
    "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
}]

El siguiente es un ejemplo del archivo actions.json que especifica las acciones authenticate-cognito y 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
}]

Para obtener más información, consulte Reglas del oyente.

Flujo de autenticación

El siguiente diagrama de red es una representación visual de cómo utiliza Application Load Balancer OIDC para autenticar a los usuarios.

Los elementos numerados que siguen, destacan y explican los elementos que se muestran en el diagrama de red anterior.

Cada nueva solicitud atraviesa los pasos 1 a 11, mientras que las solicitudes posteriores atraviesan los pasos 9 a 11. Es decir, todas las solicitudes subsiguientes comienzan en el paso 9 siempre que la cookie no haya caducado.

La cookie de AWSALBAuthNonce se agrega al encabezado de la solicitud después de que el usuario se autentique en el IdP. Esto no cambia la forma en que Equilibrador de carga de aplicación procesa las solicitudes de redireccionamiento del IdP.

Si el IdP proporciona un token de actualización válido en el token de ID, el equilibrador de carga lo guarda y lo utiliza para actualizar las notificaciones de usuario cada vez que venza el token de acceso, hasta que se agote la sesión o hasta que se produzca un error en la actualización del IdP. Si el usuario cierra la sesión, se produce un error en la actualización y el equilibrador de carga redirige al usuario al punto de conexión de autorización de IdP. De este modo, el equilibrador de carga puede dejar de funcionar después de que el usuario cierre la sesión. Para obtener más información, consulte Tiempo de espera de la sesión.

Codificación de las notificaciones de usuario y verificación de firmas

Después de que el equilibrador de carga autentica a un usuario correctamente, envía las notificaciones de usuario recibidas del IdP al destino. El equilibrador de carga firma la notificación de usuario para que las aplicaciones puedan verificar la firma y comprobar que el equilibrador de carga ha enviado las notificaciones.

Los tokens de acceso y las reclamaciones de los usuarios son diferentes de los tokens de identificación. Los tokens de acceso y las reclamaciones de usuario solo permiten el acceso a los recursos del servidor, mientras que los tokens contienen información adicional para autenticar a un usuario. El Application Load Balancer crea un nuevo token de acceso al autenticar a un usuario y solo pasa los tokens de acceso y los reclamos al backend; sin embargo, no pasa la información del token de ID.

Estos tokens siguen el JWT formato pero no son identificadores. El JWT formato incluye un encabezado, una carga útil y una firma URL codificados en base64 e incluye caracteres de relleno al final. Un Application Load Balancer utiliza ES256 (ECDSAmediante P-256 ySHA256) para generar la firma. JWT

El JWT encabezado es un JSON objeto con los siguientes campos:

{
   "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 JWT carga útil es un JSON objeto que contiene las solicitudes de usuario recibidas del punto final de información de usuario del IdP.

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

Si quieres que el balanceador de cargas cifre las reclamaciones de los usuarios, debes configurar el grupo objetivo para que las utilice. HTTPS Además, como práctica recomendada de seguridad, le recomendamos que restrinja sus objetivos para que solo reciban tráfico de su Application Load Balancer. Para lograrlo, configura el grupo de seguridad de tus objetivos para que haga referencia al ID del grupo de seguridad del balanceador de cargas.

Para garantizar la seguridad, debe verificar la firma antes de realizar cualquier autorización basada en las afirmaciones y validar que el signer campo del JWT encabezado contenga el Application Load ARN Balancer esperado.

Para obtener la clave pública, obtenga el ID de la clave del JWT encabezado y utilícelo para buscar la clave pública en el punto final. El punto de conexión de cada región de AWS es el siguiente:

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

Para AWS GovCloud (US), los puntos finales son los siguientes:

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

El siguiente ejemplo muestra cómo obtener la identificación de clave, la clave pública y la carga 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'])

El siguiente ejemplo muestra cómo obtener la identificación de clave, la clave pública y la carga 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'])

Tiempo de espera

Tiempo de espera de la sesión

El token de actualización y el tiempo de espera de la sesión funcionan juntos de la siguiente manera:

Tiempo de espera de inicio de sesión de cliente

El cliente debe iniciar y completar el proceso de autenticación en 15 minutos. Si un cliente no completa la autenticación dentro del límite de 15 minutos, recibe un error HTTP 401 del balanceador de cargas. Este tiempo de espera no se puede cambiar ni eliminar.

Por ejemplo, si un usuario carga la página de inicio de sesión a través del Equilibrador de carga de aplicación, debe completar el proceso de inicio de sesión en 15 minutos. Si el usuario espera e intenta iniciar sesión una vez transcurrido el tiempo de espera de 15 minutos, el balanceador de cargas devuelve un error 401. HTTP El usuario tendrá que actualizar la página e intentar iniciar sesión de nuevo.

Cierre de sesión de autenticación

Cuando una aplicación necesita cerrar la sesión de un usuario autenticado, debe establecer el tiempo de vencimiento de la cookie de sesión de autenticación en -1 y redirigir al cliente al punto de conexión de cierre de sesión de IdP (si el IdP admite uno). Para evitar que los usuarios reutilicen una cookie eliminada, le recomendamos que configure un tiempo de vencimiento del token de acceso tan breve como sea razonable. Si un cliente proporciona a un balanceador de carga una cookie de sesión que tiene un token de acceso caducado con un token que no se NULL actualiza, el balanceador de carga contacta con el IdP para determinar si el usuario sigue conectado.

La página de inicio de cierre de sesión del cliente es una página no autenticada. Esto significa que no puede estar detrás de una regla de Equilibrador de carga de aplicación que requiera autenticación.