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.

Prepare-se para usar um OIDC IdP compatível

Faça o seguinte se você estiver usando um OIDC IdP compatível 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 retorno de chamada URL nas configurações do cliente do aplicativo 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 authenticate-oidc ação authenticate-cognito e são compatíveis somente com HTTPS ouvintes. Para obter descrições dos campos correspondentes, consulte AuthenticateCognitoActionConfige AuthenticateOidcActionConfigna versão 01/12/2015 do Elastic Load Balancing API Reference.

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 secure atributo, porque a autenticação do usuário requer um HTTPS ouvinte. Esse cookie contém o SameSite=None atributo com solicitações CORS (compartilhamento de recursos entre origens).

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 oferecem suporte a valores de cookie URL codificados.

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 obter 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ó são compatíveis com IPv4 a comunicação com esses endpoints. Se seu IdP usa endereços públicos, garanta que os grupos de segurança do seu balanceador de carga e a rede ACLs para você VPC permitam o acesso aos endpoints. Ao usar um balanceador de carga interno ou o tipo de endereço IPdualstack-without-public-ipv4, um NAT gateway pode permitir que o balanceador de carga se comunique com os endpoints. Para obter mais informações, consulte Princípios básicos do NAT gateway no Guia do VPC usuário da Amazon.

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 obter 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 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 obter 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 token de acesso ao autenticar um usuário e apenas transmite os tokens de acesso e as declarações para o backend, porém não transmite as informações do token de ID.

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

O JWT cabeçalho é um JSON objeto 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 JWT carga é um JSON objeto que contém as declarações do usuário recebidas do endpoint de informações do usuário do IdP.

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

Se você quiser que o balanceador de carga criptografe suas declarações de usuário, você deve configurar seu grupo-alvo para uso. HTTPS Além disso, como prática de segurança, recomendamos que você restrinja seus destinos para receber apenas tráfego do seu Application Load Balancer. Você pode fazer isso configurando o grupo de segurança de seus destinos para fazer referência ao ID do grupo de segurança do balanceador de carga.

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 JWT cabeçalho contém o Application Load ARN Balancer esperado.

Para obter a chave pública, obtenha o ID da chave do JWT cabeçalho e use-o para pesquisar a chave pública no 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 dentro do limite de 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 depois que o tempo limite de 15 minutos expirar, o balanceador de carga retornará um erro 401. HTTP 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 a um balanceador de carga um cookie de sessão que tenha um token de acesso expirado com um token sem NULL atualização, 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.