Usar a federação baseada em SAML para acesso da API à AWS Visão geral da configuração de federação baseada em SAML 2.0 Visão geral da função para permitir acesso federado do SAML aos seus recursos da AWS Identificar exclusivamente os usuários na federação baseada em SAML

Federação SAML 2.0

A AWS dá suporte à federação de identidades com o SAML 2.0 (Security Assertion Markup Language 2.0), um padrão aberto que muitos provedores de identidade (IdPs) usam. Esse recurso permite a autenticação única (SSO) federada, para que os usuários possam fazer login no AWS Management Console ou chamar as operações de API da AWS sem que você precise criar um usuário do IAM para todos em sua organização. Ao usar o SAML, simplifique o processo de configuração da federação com a AWS, pois poderá usar o serviço do IdP, em vez de gravar o código de proxy de identidade personalizado.

A federação do IAM é compatível com estes casos de uso:

Acesso federado para permitir que um usuário ou aplicativo na sua organização chame operações de API da AWS. Use uma declaração do SAML (como parte da resposta de autenticação) gerada na sua organização para obter credenciais de segurança temporárias. Este cenário é semelhante a outros cenários de federação compatíveis com o IAM, como os descritos em Solicitação de credenciais de segurança temporárias e Federação OIDC. No entanto, os IdPs baseados no SAML 2.0 da sua organização lidam com muitos detalhes em tempo de execução para realizar a verificação de autenticação e autorização. Esse é o cenário discutido nesse tópico.
Logon único (SSO) baseado na web para o AWS Management Console da sua organização. Os usuários podem entrar em um portal em sua organização hospedado por um IdP compatível com SAML 2.0, selecionar uma opção para acessar a AWS e ser redirecionado para o console sem precisar fornecer informações de login adicionais. Você pode usar um IdP do SAML de terceiros para estabelecer acesso ao SSO para o console ou pode criar um IdP personalizado para habilitar o acesso ao console para os usuários externos. Para obter mais informações sobre a criação de um IdP personalizado, consulte Habilitar o acesso do agente de identidades personalizado ao console da AWS.

Tópicos

Usar a federação baseada em SAML para acesso da API à AWS

Imagine que você deseja fornecer uma maneira para os funcionários copiarem dados de seus computadores para uma pasta de backup. Crie um aplicativo que possa ser executado pelos usuários em seus computadores. No backend, a aplicação lê e grava objetos em um bucket do S3. Os usuários não têm acesso direto à AWS. Em vez disso, o processo seguinte é usado:

Obter credenciais temporárias de segurança baseadas em uma declaração do SAML

Um usuário na sua organização usa um aplicativo do cliente para solicitar a autenticação do IdP da sua organização.
O IdP autentica o usuário em relação ao armazenamento de identidades da sua organização.
O IdP cria uma declaração do SAML com informações sobre o usuário e a envia para o aplicativo do cliente.
O aplicativo do cliente chama a API do AWS STS AssumeRoleWithSAML, transmitindo o ARN do provedor SAML, o ARN da função a ser assumida e a declaração do SAML do IdP.
A resposta da API para o aplicativo do cliente inclui credenciais de segurança temporárias.
A aplicação cliente usa as credenciais de segurança temporárias para chamar as operações de API do Amazon S3.

Visão geral da configuração de federação baseada em SAML 2.0

Antes de usar a federação baseada em SAML 2.0, como descrito no diagrama e no cenário anterior, configure seu IdP da organização e sua Conta da AWS para confiarem uns nos outros. O processo geral para configurar essa confiança é descrito nas etapas a seguir. Dentro da sua organização, é necessário ter um IdP que seja compatível com SAML 2.0, como o Microsoft Active Directory Federation Service (AD FS, parte do Windows Server), Shibboleth ou outro provedor compatível com o SAML 2.0.

nota

Para melhorar a resiliência da federação, recomendamos que você configure seu IdP e sua federação da AWS para oferecer suporte a vários endpoints de login do SAML. Para obter detalhes, consulte o artigo do AWS Security Blog How to use regional SAML endpoints for failover.

Para configurar o IdP da sua organização e a AWS para confiarem entre si

Registre a AWS como provedora de serviços (SP) com o IdP da sua organização. Use o documento de metadados SAML de https://region-code.signin.aws.amazon.com/static/saml-metadata.xml

Para obter uma lista dos possíveis valores de region-code, consulte a coluna Região em Endpoints de login da AWS.

Ou você também pode usar o documento de metadados SAML em https://signin.aws.amazon.com/static/saml-metadata.xml .
Usando o IdP da sua organização, você gera um arquivo XML de metadados equivalente que pode descrever seu IdP como um provedor de identidade do IAM na AWS. Ele deve incluir o nome do emissor, uma data de criação, uma data de expiração e chaves que a AWS pode usar para validar as respostas de autenticação (declarações) da sua organização.
No console do IAM, crie uma entidade de provedor de identidade do SAML. Como parte do processo, faça upload do documento de metadados do SAML que foi produzido pelo IdP na sua organização em Passo 2. Para ter mais informações, consulte Criar um provedor de identidades SAML no IAM.
No IAM, crie uma ou mais funções do IAM. Na política de confiança da função, defina o provedor do SAML como principal, o que estabelece uma relação de confiança entre sua organização e a AWS. A política de permissões da função estabelece o que os usuários da sua organização têm permissão para fazer na AWS. Para ter mais informações, consulte Criar uma função para um provedor de identidade de terceiros (federação).

nota
Os IdPs do SAML usados em uma política de confiança de função devem estar na mesma conta em que a função está.
No IdP da sua organização, você define asserções que mapeiam usuários ou grupos em sua organização para as funções do IAM. Observe que usuários e grupos diferentes na sua organização podem ser mapeados para funções do IAM distintas. As etapas exatas para executar o mapeamento dependem do IdP que você estiver usando. No cenário anterior de uma pasta do Amazon S3 para usuários, é possível que todos os usuários sejam mapeados para a mesma função que fornece as permissões do Amazon S3. Para ter mais informações, consulte Configurar declarações SAML para a resposta de autenticação.

Se o seu IdP habilitar o SSO para o console da AWS, configure a duração máxima de sessões do console. Para ter mais informações, consulte Habilitar o acesso de usuários federados SAML 2.0 ao AWS Management Console.

nota
A implementação da federação SAML 2.0 da AWS não oferece suporte a declarações SAML criptografadas entre o provedor de identidade do IAM e a AWS. No entanto, o tráfego entre os sistemas do cliente e a AWS é transmitido por um canal criptografado (TLS).
No aplicativo que você estiver criando, chame a API AssumeRoleWithSAML do AWS Security Token Service, transmitindo para ela o ARN do provedor SAML criado em Passo 3, o ARN da função para supor que você criou em Passo 4 e a declaração do SAML sobre o usuário atual que você obtém do seu IdP. A AWS garante que a solicitação para assumir a função venha do IdP referenciado no provedor de SAML.

Para obter mais informações, consulte AssumeRoleWithSAML na Referência da API do AWS Security Token Service.
Se a solicitação for bem-sucedida, a API retorna um conjunto de credenciais de segurança temporárias, que o aplicativo pode usar para fazer solicitações assinadas para a AWS. Sua aplicação tem informações sobre o usuário atual e pode acessar pastas específicas do usuário no Amazon S3, conforme descrito no cenário anterior.

Visão geral da função para permitir acesso federado do SAML aos seus recursos da AWS

A função ou as funções que você cria no IAM definem o que os usuários federados de sua organização têm permissão para fazer na AWS. Ao criar a política de confiança para a função, especifique o provedor SAML criado anteriormente como Principal. Além disso, examine a política de confiança com uma Condition, para permitir que apenas usuários que satisfaçam determinados atributos do SAML tenham acesso à função. Por exemplo, especifique que apenas usuários cujas afiliações do SAML sejam staff (conforme definido em https://openidp.feide.no) tenham permissão para acessar a função, como ilustrado pelo seguinte exemplo de política:


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

nota

Os IdPs do SAML usados em uma política de confiança de função devem estar na mesma conta em que a função está.

Para obter mais informações sobre as chaves SAML que você pode verificar em uma política, consulte Chaves disponíveis para federação do AWS STS com base em SAML.

Você pode incluir endpoints regionais para o atributo saml:aud em https://region-code.signin.aws.amazon.com/static/saml-metadata.xml. Para obter uma lista dos possíveis valores de region-code (região-código), consulte a coluna Region (Região) em AWS Sign-In endpoints (Endpoints de login da ).

Para a política de permissões na função, especifique as permissões como faria para qualquer função. Por exemplo, se os usuários da sua organização tiverem permissão para administrar instâncias do Amazon Elastic Compute Cloud, você deverá permitir explicitamente as ações do Amazon EC2 na política de permissões, como aquelas na política gerenciada AmazonEC2FullAccess.

Identificar exclusivamente os usuários na federação baseada em SAML

Quando você cria políticas de acesso no IAM, geralmente é útil poder especificar permissões com base na identidade dos usuários. Por exemplo, para usuários federados usando o SAML, uma aplicação pode manter informações no Amazon S3 usando uma estrutura como esta:


myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3

Você pode criar o bucket (myBucket) e a pasta (app1) por meio do console do Amazon S3 ou da AWS CLI, uma vez que esses são valores estáticos. No entanto, as pastas específicas do usuário (user1, user2, user3 etc.) precisam ser criadas em tempo de execução usando código, já que o valor que identifica o usuário é desconhecido até a primeira vez que o usuário faz login, por meio do processo de federação.

Para gravar políticas que façam referência a detalhes específicos do usuário como parte de um nome de recurso, a identidade do usuário deve estar disponível nas chaves do SAML que podem ser usadas em condições de política. As seguintes chaves estão disponíveis para federação baseada em SAML 2.0 para uso em políticas do IAM. Você pode usar os valores retornados pelas seguintes chaves para criar identificadores de usuário exclusivos para recursos como pastas do Amazon S3.

saml:namequalifier. Um valor de hash com base na concatenação do valor de resposta de Issuer (saml:iss) e uma string com o ID da conta da AWS e o nome amigável (a última parte do ARN) do provedor SAML no IAM. A concatenação do ID da conta e do nome amigável do provedor SAML está disponível para as políticas do IAM como a chave saml:doc. O ID da conta e o nome do provedor devem ser separados por ‘/’ como em “123456789012/provider_name”. Para obter mais informações, consulte a chave do saml:doc em Chaves disponíveis para federação do AWS STS com base em SAML.

A combinação do NameQualifier e do Subject pode ser usada para identificar exclusivamente um usuário federado. O pseudocódigo a seguir mostra como esse valor é calculado. Nesse pseudocódigo, + indica concatenação, SHA1 representa uma função que produz um resumo de mensagens usando SHA-1 e Base64 representa uma função que produz a versão codificada em Base64 da saída de hash.

Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

Para obter mais informações sobre a chaves de política disponíveis para federação baseada em SAML, consulte Chaves disponíveis para federação do AWS STS com base em SAML.
saml:sub (string). Trata-se do assunto da solicitação, que inclui um valor que identifica de forma exclusiva um usuário individual em uma organização (por exemplo, _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).
saml:sub_type (string). Essa chave pode ser persistent, transient ou o URI Format completo dos elementos Subject e NameID usados na declaração do SAML. Um valor persistent indica que o valor em saml:sub é o mesmo para um usuário em todas as sessões. Se o valor for transient, o usuário terá um valor saml:sub diferente para cada sessão. Para obter mais informações sobre o atributo NameID do elemento Format, consulte Configurar declarações SAML para a resposta de autenticação.

O exemplo a seguir mostra uma política de permissão que usa as chaves anteriores para conceder permissões a uma pasta específica do usuário no Amazon S3. A política supõe que os objetos do Amazon S3 são identificados usando um prefixo que inclui saml:namequalifier e saml:sub. Observe que o elemento Condition inclui um teste para garantir que o saml:sub_type esteja definido como persistent. Se for definido transient, o valor do saml:sub para o usuário poderá ser diferente para cada sessão e a combinação de valores não deverá ser usada para identificar pastas específicas do usuário.


{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

Para obter mais informações sobre o mapeamento de declarações do IdP para chaves de política, consulte Configurar declarações SAML para a resposta de autenticação.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Recursos adicionais para federação OIDC

Criar um provedor de identidades SAML