As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Autenticar usuários usando um Application Load Balancer

Você pode configurar um Application Load Balancer para autenticar usuários com segurança conforme eles acessem suas aplicações. Com isso, você pode redirecionar o trabalho de autenticação de usuários para seu load balancer para que seus aplicativos possam se concentrar na respectiva lógica de negócios.

Preparação para usar um IdP compatível com OIDC

Faça o seguinte se você estiver usando um IdP compatível com OIDC com seu Application Load Balancer:

Preparação para usar o Amazon Cognito

Faça o seguinte se você estiver usando grupos de usuários do Amazon Cognito com seu Application Load Balancer:

O URL de retorno de chamada nas configurações do aplicativo cliente deve usar todas as letras minúsculas.

Para permitir que um usuário configure um balanceador de carga para usar o Amazon Cognito para autenticar usuários, você deve conceder permissão ao usuário para chamar a ação cognito-idp:DescribeUserPoolClient.

Prepare-se para usar a Amazon CloudFront

Ative as seguintes configurações se você estiver usando uma CloudFront distribuição na frente do seu Application Load Balancer:

Configurar a autenticação de usuários

Você configura a autenticação de usuários criando uma ação de autenticação para uma ou mais regras do listener. Os tipos de ação authenticate-cognito e authenticate-oidc são comportados somente por listeners HTTPS. Para obter descrições dos campos correspondentes, consulte AuthenticateCognitoActionConfige AuthenticateOidcActionConfigna versão de referência da API Elastic Load Balancing 2015-12-01.

O load balancer envia um cookie de sessão para o cliente a fim de manter o status de autenticação. Esse cookie sempre contém o atributo secure, pois a autenticação do usuário requer um listener HTTPS. Esse cookie contém o atributo SameSite=None com solicitações CORS (cross-origin resource sharing, compartilhamento de recursos de origem cruzada).

Para um balanceador de carga compatível com várias aplicações que exigem autenticação independente de cliente, cada regra de receptor com uma ação de autenticação deve ter um nome de cookie exclusivo. Isso garante que os clientes sempre sejam autenticados com o IdP antes de serem roteados para o grupo de destino especificado na regra.

Os Application Load Balancers não são compatíveis com valores de cookie codificados por URL.

Por padrão, o campo SessionTimeout é definido com 7 dias. Se desejar sessões menores, pode configurar um tempo limite de sessão de 1 segundo. Para ter mais informações, consulte Tempo limite de sessão.

Defina o campo OnUnauthenticatedRequest de acordo com seu aplicativo. Por exemplo: .

O load balancer precisa se comunicar com o endpoint de token do IdP (TokenEndpoint) e o endpoint de informações do usuário do Idp (UserInfoEndpoint). Os Application Load Balancers só oferecem suporte a IPv4 ao se comunicar com esses endpoints. Se seu IdP usa endereços públicos, garanta que os grupos de segurança do seu balanceador de carga e as ACLs de rede da sua VPC permitam acesso aos endpoints. Ao usar um balanceador de carga interno ou o tipo de endereço IPdualstack-without-public-ipv4, um gateway NAT pode permitir que o balanceador de carga se comunique com os endpoints. Para obter mais informações, consulte Fundamentos de gateway NAT no Guia do usuário da Amazon VPC.

Use o comando create-rule a seguir para configurar a autenticação de usuários.

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

Veja a seguir um exemplo do arquivo actions.json que especifica uma ação authenticate-oidc e uma ação forward. AuthenticationRequestExtraParams permite que você transmita parâmetros extras para um IdP durante a autenticação. Siga a documentação fornecida pelo seu provedor de identidade para determinar os campos que são compatíveis

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

Veja a seguir um exemplo de configuração do arquivo actions.json, que especifica uma ação authenticate-cognito e uma ação 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 ter mais informações, consulte Regras do listener.

Fluxo de autenticação

O diagrama de rede a seguir é uma representação visual de como um Application Load Balancer usa o OIDC para autenticar usuários.

Os itens numerados abaixo destacam e explicam os elementos apresentados no diagrama de rede anterior.

Cada nova solicitação passa pelas etapas de 1 a 11, enquanto as solicitações subsequentes passam pelas etapas de 9 a 11. Ou seja, todas as solicitações subsequentes começam na etapa 9, desde que o cookie não tenha expirado.

O cookie AWSALBAuthNonce é adicionado ao cabeçalho da solicitação depois que o usuário fizer autenticação no IdP. Isso não muda a forma como o Application Load Balancer processa as solicitações de redirecionamento do IdP.

Se o IdP fornecer um token de atualização válido no token de ID, o load balancer salvará o token de atualização e o usará para atualizar as solicitações do usuário toda vez que o token de acesso expirar, até o momento em que a sessão expirar ou a atualização do IdP falhar. Se o usuário encerrar a sessão, a atualização falhará e o load balancer o redirecionará para o endpoint de autorização do IdP. Isso permite que o load balancer suspenda as sessões depois que o usuário encerra a sessão. Para ter mais informações, consulte Tempo limite de sessão.

Verificação de assinatura e codificação de reivindicações de usuário

Depois que o load balancer autentica com êxito um usuário, envia as solicitações do usuário recebidas do IdP para o destino. O load balancer assina a solicitação do usuário para que os aplicativos possam verificar a assinatura e verificar se as solicitações foram enviadas pelo load balancer.

Os tokens de acesso e as reivindicações de usuário são diferentes dos tokens de ID. Os tokens de acesso e as reivindicações de usuário só permitem o acesso aos recursos do servidor, enquanto os tokens de ID contêm informações adicionais para autenticar um usuário. O Application Load Balancer cria um novo token de acesso ao autenticar um usuário e só passa os tokens de acesso e as declarações para o back-end, mas não passa as informações do token de ID.

Esses tokens seguem o formato JWT, mas não são tokens de ID. O formato JWT inclui um cabeçalho, carga e assinatura que são codificados em URL base64 e incluem caracteres de preenchimento no final. Um Application Load Balancer usa ES256 (ECDSA usando P-256 e SHA256) para gerar a assinatura JWT.

O cabeçalho JWT contém um objeto JSON com os seguintes 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"
}

A carga JWT é um objeto JSON que contém o usuário as solicitações do usuário recebidas do endpoint de informações do usuário do IdP.

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

Como o load balancer não criptografa as solicitações do usuário, é recomendável configurar o grupo de destino para usar HTTPS. Se você configurar o grupo de destino para usar HTTP, lembre-se de restringir o tráfego para seu load balancer usando security groups.

Para garantir a segurança, você deve verificar a assinatura antes de fazer qualquer autorização com base nas declarações e validar se o signer campo no cabeçalho do JWT contém o ARN esperado do Application Load Balancer.

Para obter a chave pública, obtenha o ID de chave de cabeçalho JWT e use-o para procurar a chave pública do endpoint. O endpoint para cada região da AWS é o seguinte:

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

Para AWS GovCloud (US), os endpoints são os seguintes:

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

O exemplo a seguir mostra como obter o ID de chave, a chave pública e a carga útil em 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'])

O exemplo a seguir mostra como obter o ID de chave, a chave pública e a carga útil em 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'])

Timeout (Tempo limite)

Tempo limite de sessão

O token de atualização e o tempo limite de sessão funcionam juntos da seguinte forma:

Tempo limite de login do cliente

O cliente deve iniciar e concluir o processo de autenticação em até 15 minutos. Se um cliente não conseguir concluir a autenticação durante os 15 minutos, ele receberá um erro HTTP 401 do balanceador de carga. Não é possível alterar nem remover esse tempo limite.

Por exemplo, se um usuário carregar a página de login por meio do Application Load Balancer, ele deverá concluir o processo de login em até 15 minutos. Se o usuário esperar e tentar fazer login após a expiração do tempo limite de 15 minutos, o balanceador de carga retornará um erro HTTP 401. O usuário precisará atualizar a página e tentar fazer login novamente.

Sair da autenticação

Quando um aplicativo precisa encerrar a sessão de um usuário autenticado, deve definir o tempo de expiração do cookie de sessão de autenticação como –1 e redirecionar o cliente para o endpoint de logout do IdP (se o IdP comportar um). Para evitar que os usuários reutilizem um cookie excluído, é recomendável configurar um tempo de expiração o mais razoável possível para o token de acesso. Se um cliente fornecer um balanceador de carga com um cookie de sessão que contenha um token de acesso expirado com um token de atualização não nulo, o balanceador de carga entrará em contato com o IdP para determinar se o usuário ainda está conectado.

A página inicial de logout do cliente é uma página não autenticada. Isso significa que ela não pode estar protegida por uma regra do Application Load Balancer que exija autenticação.