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 usuários com segurança à medida que acessar 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 IdPs sociais, como Amazon, Facebook ou Google, e de grupos de usuários compatíveis com o Amazon Cognito.

  • Autentique usuários por meio de identidades corporativas, usando o SAML, LDAP ou Microsoft AD, e de grupos de usuários compatíveis com o Amazon Cognito.

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

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

  • Crie um novo aplicativo OIDC em seu IdP. 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.

  • Permita que um dos seguintes URLs de redirecionamento no aplicativo IdP, o que seus usuários usarão, no qual DNS é o nome de domínio de seu load balancer e CNAME é o alias DNS de 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, consulteGrupos de usuários do Amazon CognitonoGuia 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, consulteComo configurar um cliente da aplicação do grupo de usuáriosnoGuia do desenvolvedor do Amazon Cognito.

  • Crie um domínio de grupo de usuários. Para obter mais informações, consulteAdicionar um nome de domínio ao grupo de usuáriosnoGuia 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, consulteAdicionar um acesso social a um grupo de usuáriosouAdicionar login com um IdP SAML a um grupo de usuáriosnoGuia do desenvolvedor do Amazon Cognito.

  • Permita que os seguintes URLs de redirecionamento no campo de URL de retorno de chamada para o Amazon Cognito, no qual DNS é o nome de domínio de seu load balancer e CNAME é o alias DNS de seu aplicativo (se estiver usando um):

    • https://DNS/oauth2/idpresponse

    • https://CNAME/oauth2/idpresponse

  • Permita que seu domínio do grupo de usuários no URL de retorno de chamada do aplicativo do 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

Para permitir que um usuário do IAM configure um load balancer para usar o Amazon Cognito para autenticar usuários, você deve conceder permissão ao usuário para chamar ocognito-idp:DescribeUserPoolClientAção .

Preparação para usar o Amazon CloudFront

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

  • Encaminhar cabeçalhos de solicitação (todos) — Garante que CloudFront Os não armazenam em cache respostas para 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 armazenamento em cache está ativado, os proprietários de um CloudFront distribuição pode definir o time-to-live (TTL) valor a expirar antes que o cookie de autenticação expire.

  • Encaminhamento de string de consulta e armazenamento em cache (todos) — Garante que o load balancer tenha acesso aos parâmetros da string de consulta necessários para autenticar o usuário com o IdP.

  • Encaminhamento de cookies (todos) — Garante que CloudFront Encaminha todos os cookies de autenticação para o 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, consulteAuthenticateCognitoActionConfigeAuthenticateOidcActionConfignoReferência da API do Elastic Load Balancing versão de 01/12/2015.

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 suporta vários aplicativos que exigem autenticação de cliente independente, cada regra de listener 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 de destino especificado na regra.

Os Application Load Balancers não comportam 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 obter mais informações, consulte Tempo limite de 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 oferecem uma visualização personalizada para um usuário que está conectado ou uma visualização geral para um usuário que não está conectado—Para oferecer suporte a esse tipo de aplicativo, use oallowopçã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 que carrega a cada poucos segundos—Se você usar odenyOpção, o load balancer retornará um erro HTTP 401 Não autorizado para chamadas AJAX que não têm informações de autenticação. Mas se o usuário tiver informações de autenticação expiradas, 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, consulteNoções básicas de gateway NATnoManual 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 doactions.jsonarquivo que especifica umauthenticate-oidcAção e umforwardAçã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 com suporte

[{ "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 enviará o usuário de volta para o load balancer com um código de concessão de autorização.

  4. O load balancer apresenta o código de concessão de autorização para o endpoint de token do 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 para o 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ário.

  8. O Application Load Balancer redireciona o usuário com oAWSELBcookie de sessão de autenticação para o URI original. Como a maioria dos navegadores restringe o tamanho do cookie para 4K, o load balancer fragmenta um cookie com tamanho superior a 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 naX-AMZN-OIDC-*Cabeçalhos HTTP definidos. Para obter mais informações, consulte Verificação de codificação e assinatura de reivindicações do usuário.

  10. O destino 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 1 a 11, enquanto as solicitações subsequentes passam pelas etapas 9 a 11. Ou seja, todas as solicitações subsequentes começam 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 de 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 é definido como 40 anos. O motivo da longa expiração é garantir que o navegador sempre reproduza o cookie. 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. O tempo limite da sessão está incluído no valor do cookie Auth, que também é criptografado.

Verificação de codificação e assinatura de reivindicações do 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.

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á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 carregam informações adicionais para autenticar um usuário. O Application Load Balancer autentica o usuário e passa apenas tokens de acesso e reivindicações para o back-end, mas não transmite 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. A assinatura JWT é ECDSA+ P-256+SHA256.

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 de chave no cabeçalho JWT e use-o para procurar a chave pública do endpoint. O endpoint para cadaAWSA região é a seguinte:

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

para oAWS 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 a chave pública em 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 a chave pública em 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'])

Observe que 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 de 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 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 relogin.

    • Se o tempo limite da sessão IdP for igual ou menor do que o tempo limite da sessão do Application Load Balancer, o usuário será solicitado a fornecer credenciais para fazer login novamente. Depois que o usuário fizer 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 atinja o back-end.

  • Se o tempo limite da sessão for maior que o tempo de expiração do token de acesso e o IdP não comportar tokens de atualização, o load balancer manterá a sessão de autenticação até o momento em que ela expirar. Em seguida, ele faz com que o usuário faça 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

Um cliente deve iniciar e concluir o processo de autenticação em 15 minutos. Se um cliente não 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 ou 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 aguardar e tentar fazer login após o tempo limite de 15 minutos expirar, o balanceador de carga retornará um erro HTTP 401. O usuário terá que 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 um load balancer com um cookie de sessão que tenha um token de acesso expirado com um token de atualização não nulo, o load balancer 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 ele não pode estar por trás de uma regra do Application Load Balancer que requer autenticação.

  • Quando uma solicitação é enviada para o 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 logout, ele deverá emitir um redirecionamento para o endpoint de logout do IdP, por exemplo, oEndpoint LOGOUTDocumentado noGuia do desenvolvedor do Amazon Cognito.

    • Se o IdP não tiver um endpoint de logout, a solicitação voltará para a página inicial de logout do cliente e o processo de login será reiniciado.

  • Supondo que o IdP tenha um endpoint de logout, o IdP deve expirar tokens de acesso e atualizar tokens e redirecionar o usuário de volta para a página inicial de logout do cliente.

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