Sobre a federação baseada em SAML 2.0 - AWS Identity and Access Management

Sobre a federação baseada em 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:

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 back-end, o aplicativo 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
  1. Um usuário na sua organização usa um aplicativo do cliente para solicitar a autenticação do IdP da sua organização.

  2. O IdP autentica o usuário em relação ao armazenamento de identidades da sua organização.

  3. O IdP cria uma declaração do SAML com informações sobre o usuário e a envia para o aplicativo do cliente.

  4. 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.

  5. A resposta da API para o aplicativo do cliente inclui credenciais de segurança temporárias.

  6. 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 entre si. 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.

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

  1. Registre a AWS com seu IdP. No IdP da sua organização, registre a AWS como um provedor de serviços (SP), usando o documento de metadados do SAML que você obtém a partir do seguinte URL:

    https://signin.aws.amazon.com/static/saml-metadata.xml

  2. 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.

  3. 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 obter mais informações, consulte Criação de provedores de identidade SAML do IAM.

  4. 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 obter mais informações, consulte Criar uma função para um provedor de identidade de terceiros (federação).

  5. 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 obter mais informações, consulte Configuração de 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 obter 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).

  6. No aplicativo que você estiver criando, chame a API AWS Security Token Service do AssumeRoleWithSAML, 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.

  7. 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-WITHOUT-HYPHENS: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"]} } }] }

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.

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 Configuração de 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 Configuração de declarações SAML para a resposta de autenticação.