Autenticar usuários usando um Application Load Balancer - Elastic Load Balancing

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 com segurança os usuários à medida que eles acessam seus aplicativos. 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.

Os casos de uso a seguir são comportados:

  • Autentique usuários por meio de um provedor de identidade (IdP) compatível com OpenID Connect (OIDC).

  • Autentique usuários por meio de redes sociais IdPs, como Amazon, Facebook ou Google, por meio dos grupos de usuários suportados pelo Amazon Cognito.

  • Autentique usuários por meio de identidades corporativas, usando SAML, LDAP ou Microsoft AD, por meio dos grupos de usuários suportados pelo Amazon Cognito.

Prepare-se para usar um IdP compatível com OIDC

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

  • Crie um novo aplicativo OIDC em seu IdP. O DNS do IdP deve ser solucionável publicamente.

  • Você deve configurar um ID de cliente e um segredo de cliente.

  • Obtenha os seguintes endpoints publicados pelo IdP: autorização, token e informações de usuário. Você pode localizar essas informações na configuração.

  • As entradas de DNS para os endpoints devem ser resolvidas publicamente, mesmo que sejam resolvidas para endereços IP privados.

  • Permita um dos seguintes URLs de redirecionamento em seu aplicativo IdP, o que seus usuários usarem, em que DNS é o nome de domínio do seu balanceador de carga e CNAME é o alias de DNS do seu aplicativo:

    • https://DNS/oauth2/idpresponse

    • https://CNAME/oauth2/idpresponse

Preparação para usar o Amazon Cognito

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

  • Criar um grupo de usuários. Para obter mais informações, consulte Grupos de usuários do Amazon Cognito no Guia do desenvolvedor do Amazon Cognito.

  • Crie um cliente de grupo de usuários. Você deve configurar o cliente para gerar um segredo de cliente, usar um fluxo de concessão de código e comportar os mesmos escopos OAuth usados pelo load balancer. Para obter mais informações, consulte Configurar um cliente da aplicação do grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

  • Crie um domínio de grupo de usuários. Para obter mais informações, consulte Adicionar um nome de domínio para seu grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

  • Verifique se o escopo solicitado retorna um token de ID. Por exemplo, o escopo padrão, openid retorna um token de ID, mas o aws.cognito.signin.user.admin escopo não.

  • Para federar com um IdP social ou corporativo, habilite o IdP na seção de federação. Para obter mais informações, consulte Adicionar login social a um grupo de usuários ou Adicionar login com um SAML IdP a um grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

  • Permita os seguintes URLs de redirecionamento no campo URL de retorno de chamada do Amazon Cognito, em que DNS é o nome de domínio do seu balanceador de carga e CNAME é o alias de DNS do seu aplicativo (se você estiver usando um):

    • https://DNS/oauth2/idpresponse

    • https://CNAME/oauth2/idpresponse

  • Permita o domínio do grupo de usuários no URL de retorno de chamada do seu aplicativo IdP. Use o formato de seu IdP. Por exemplo:

    • https://domain-prefix.auth.região. amazoncognito.com/saml2/idpresponse

    • https://user-pool-domain/oauth2/idpresponse

O URL de retorno de chamada 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 ao usuário permissão para chamar acognito-idp:DescribeUserPoolClient ação.

Preparação 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:

  • Encaminhar cabeçalhos de solicitação (todos) — Garante que CloudFront não armazene em cache as respostas das solicitações autenticadas. Isso impede que sejam exibidos no cache após a expiração da sessão de autenticação. Como alternativa, para reduzir esse risco enquanto o cache está ativado, os proprietários de uma CloudFront distribuição podem definir o valor time-to-live (TTL) para expirar antes que o cookie de autenticação expire.

  • Encaminhamento e armazenamento em cache da sequência de caracteres de consulta (todos) — Garante que o balanceador de carga tenha acesso aos parâmetros da sequência de caracteres de consulta necessários para autenticar o usuário com o IdP.

  • Encaminhamento de cookies (todos) — Garante que todos os cookies de autenticação sejam CloudFront encaminhados para o balanceador de carga.

Configurar autenticação do usuário

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 que ofereça suporte a vários aplicativos que exigem autenticação independente do cliente, cada regra de ouvinte com uma ação de autenticação deve ter um nome de cookie exclusivo. Isso garante que os clientes sejam sempre autenticados com o IdP antes de serem roteados para o grupo-alvo especificado na regra.

Os Application Load Balancers não são compatíveis com valores de cookies codificados em 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 obter mais informações, consulte Tempo limite da sessão.

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

  • Aplicativos que exigem que o usuário faça login usando uma identidade social ou corporativa — Isso é suportado pela opção padrão,authenticate. Se o usuário não estiver conectado, o load balancer redirecionará a solicitação para o endpoint de autorização do IdP e o IdP solicitará que o usuário faça login usando sua interface de usuário.

  • Aplicativos que fornecem uma visualização personalizada para um usuário conectado ou uma visão geral para um usuário que não está conectado — Para oferecer suporte a esse tipo de aplicativo, use aallow opção. Se o usuário estiver conectado, o load balancer fornecerá as solicitações do usuário e o aplicativo poderá oferecer uma visualização personalizada. Se o usuário não estiver conectado, o load balancer encaminhará a solicitação sem as solicitações do usuário e o aplicativo poderá oferecer uma visualização geral.

  • Aplicativos de página única com JavaScript isso carregados a cada poucos segundos — Se você usar adeny opção, o balanceador de carga retornará um erro HTTP 401 não autorizado às chamadas AJAX que não têm informações de autenticação. Mas se o usuário tiver expirado as informações de autenticação, ele redirecionará o cliente para o endpoint de autorização do IdP.

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). Verifique se os security groups para seu load balancer e as ACLs de rede para a VPC permitem que acesso de saída a esses endpoints. Verifique se a VPC tem acesso à Internet. Se você tiver um load balancer interno, use um gateway NAT para permitir que o load balancer acesse esses endpoints. Para obter mais informações, consulte Noções básicas do gateway NAT no Guia do usuário do 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 doactions.json arquivo que especifica umaauthenticate-oidc ação e umaforward ação. AuthenticationRequestExtraParamspermite que você passe parâmetros extras para um IdP durante a autenticação. Siga a documentação fornecida pelo seu provedor de identidade para determinar os campos suportados

[{ "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 o OIDC para autenticar usuários.


                    Como o Application Load Balancer autentica usuários via OIDC

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

  1. O usuário envia uma solicitação HTTPS para um site hospedado por trás de um Application Load Balancer. Quando as condições para uma regra com uma ação de autenticação são atendidas, o load balancer verifica a existência de um cookie de sessão de autenticação nos cabeçalhos de solicitação.

  2. Se o cookie não estiver presente, o load balancer redirecionará o usuário para o endpoint de autorização do IdP para que o IdP possa autenticar o usuário.

  3. Depois que o usuário é autenticado, o IdP o envia de volta ao balanceador de carga com um código de concessão de autorização.

  4. O balanceador de carga apresenta o código de concessão de autorização ao endpoint do token IdP.

  5. Ao receber um código de concessão de autorização válido, o IdP fornece o token de ID e o token de acesso ao Application Load Balancer.

  6. Em seguida, o Application Load Balancer envia o token de acesso ao endpoint de informações do usuário.

  7. O endpoint de informações do usuário troca o token de acesso por reivindicações de usuários.

  8. O Application Load Balancer redireciona o usuário com o cookie da sessão deAWSELB autenticação para o URI original. Como a maioria dos navegadores limita o tamanho do cookie a 4K, o balanceador de carga fragmenta um cookie com tamanho maior que 4K em vários cookies. Se o tamanho total das solicitações do usuário e do token de acesso recebidos do IdP for superior a 11K bytes, o load balancer retornará um erro HTTP 500 para o cliente e incrementará a métrica ELBAuthUserClaimsSizeExceeded.

  9. O Application Load Balancer valida o cookie e encaminha as informações do usuário para destinos no conjunto de cabeçalhosX-AMZN-OIDC-* HTTP. Para obter mais informações, consulte Codificação de reivindicações de usuários e verificação de assinatura.

  10. O alvo envia uma resposta de volta ao Application Load Balancer.

  11. O Application Load Balancer envia a resposta final ao usuário.

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, cada solicitação subsequente começa na etapa 9, desde que o cookie não tenha expirado.

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 da sessão.

nota

A expiração do cookie é diferente da expiração da sessão de autenticação. A expiração do cookie é um atributo do cookie, que é definida como 7 dias. A duração real da sessão de autenticação é determinada pelo tempo limite da sessão configurado no Application Load Balancer para o recurso de autenticação. Esse tempo limite de sessão está incluído no valor do cookie Auth, que também é criptografado.

Codificação de reivindicações de usuários e verificação de assinatura

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.

O load balancer adiciona os seguintes cabeçalhos HTTP:

x-amzn-oidc-accesstoken

O token de acesso do endpoint de token, em texto simples.

x-amzn-oidc-identity

O campo de assunto (sub) do endpoint de informações do usuário, em texto simples.

x-amzn-oidc-data

As solicitações do usuário, no formato de JSON Web Token (JWT).

Os tokens de acesso e as reivindicações de usuários são diferentes dos tokens de identificação. Os tokens de acesso e as reivindicações do usuário só permitem o acesso aos recursos do servidor, enquanto os tokens de ID carregam informações adicionais para autenticar um usuário. O Application Load Balancer autentica o usuário e só passa tokens de acesso e reivindicaçõ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, uma carga útil e uma assinatura codificados em base64 em URL e inclui 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. É também recomendável verificar a assinatura antes de fazer qualquer autorização com base nas solicitações. Para obter a chave pública, obtenha o ID da chave do cabeçalho do JWT e use-o para pesquisar a chave pública no endpoint. O endpoint para cadaAWS região é o seguinte:

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

ParaAWS 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 da chave, a chave pública e a carga útil no Python 3.x:

import jwt import requests import base64 import json # Step 1: Get the key id from JWT headers (the kid field) 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) kid = decoded_json['kid'] # Step 2: 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 3: Get the payload payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

O exemplo a seguir mostra como obter o ID da chave, chave pública e carga no Python 2.7:

import jwt import requests import base64 import json # Step 1: Get the key id from JWT headers (the kid field) 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) kid = decoded_json['kid'] # Step 2: 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 3: Get the payload payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])
Considerações
  • Esses exemplos não abordam como validar a assinatura do emissor com a assinatura no token.

  • As bibliotecas padrão não são compatíveis com o preenchimento incluído no token de autenticação do Application Load Balancer no formato JWT.

Tempo limite

Tempo limite da sessão

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

  • Se o tempo limite da sessão for menor do que a expiração do token de acesso, o load balancer respeitará o tempo limite da sessão. Se o usuário tiver uma sessão ativa com o IdP, talvez o usuário não seja solicitado a fazer login novamente. Caso contrário, o utilizador será redirecionado para fazer login.

    • Se o tempo limite da sessão do IdP for maior do que o tempo limite da sessão do Application Load Balancer, o usuário não precisará fornecer credenciais para fazer login novamente. Em vez disso, o IdP redireciona de volta para o Application Load Balancer com um novo código de concessão de autorização. Os códigos de autorização são de uso único, mesmo que não haja um novo login.

    • Se o tempo limite da sessão do IdP for igual ou menor do que o tempo limite da sessão do Application Load Balancer, o usuário deverá fornecer as credenciais para fazer login novamente. Depois que o usuário faz login, o IdP redireciona de volta para o Application Load Balancer com um novo código de concessão de autorização, e o restante do fluxo de autenticação continua até que a solicitação chegue ao back-end.

  • Se o tempo limite da sessão for maior do que a expiração do token de acesso e o IdP não oferecer suporte a tokens de atualização, o balanceador de carga manterá a sessão de autenticação até o tempo limite. Em seguida, o usuário faz login novamente.

  • Se o tempo limite de sessão for maior do que o tempo de expiração do token de acesso e o IdP comportar tokens de atualização, o load balancer atualizará a sessão de usuário toda vez que o token de acesso expirar. O load balancer fará com que o usuário faça login novamente apenas depois que a sessão de autenticação expirar ou o fluxo de atualização falhar.

Tempo limite de login do cliente

O cliente deve iniciar e concluir o processo de autenticação em 15 minutos. Se um cliente falhar em concluir a autenticação dentro do limite de 15 minutos, ele receberá um erro HTTP 401 do balanceador de carga. Esse tempo limite não pode ser alterado nem removido.

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 15 minutos. Se o usuário esperar e tentar fazer login após o término 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.

Logout de 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 de atualização não NULL, o balanceador de carga entrará em contato com o IdP para determinar se o usuário ainda está conectado.

A página inicial de encerramento de sessão do cliente é uma página não autenticada. Isso significa que ele não pode estar por trás de uma regra do Application Load Balancer que exige autenticação.

  • Quando uma solicitação é enviada ao destino, o aplicativo deve definir a expiração como -1 para todos os cookies de autenticação. Os Application Load Balancers suportam cookies de até 16K de tamanho e, portanto, podem criar até 4 fragmentos para enviar ao cliente.

    • Se o IdP tiver um endpoint de saída, ele deverá emitir um redirecionamento para o endpoint de saída do IdP, por exemplo, o endpoint LOGOUT documentado no Guia do desenvolvedor do Amazon Cognito.

    • Se o IdP não tiver um endpoint de saída, a solicitação retornará à página inicial de saída do cliente e o processo de login será reiniciado.

  • Supondo que o IdP tenha um endpoint de saída, o IdP deve expirar os tokens de acesso e os tokens de atualização e redirecionar o usuário de volta à página inicial de saída do cliente.

  • As solicitações subsequentes seguem o fluxo de autenticação original.