Concessões de Acesso do S3 e identidades de diretórios corporativos - Amazon Simple Storage Service
Como as identidades do diretório podem acessar os dados do S3

Concessões de Acesso do S3 e identidades de diretórios corporativos

Você pode usar a funcionalidade Concessões de Acesso do Amazon S3 para conceder acesso às entidades principais do AWS Identity and Access Management (IAM) (usuários ou perfis), tanto na mesma Conta da AWS quanto em outras. No entanto, em muitos casos, a entidade que acessa os dados é um usuário final de um diretório corporativo. Em vez de conceder acesso às entidades principais do IAM, você pode usar a funcionalidade Concessões de Acesso do S3 para conceder acesso diretamente aos usuários e grupos corporativos. Com a funcionalidade Concessões de Acesso do S3, você não precisa mais mapear as identidades corporativas para entidades principais intermediárias do IAM a fim de acessar os dados do S3 por meio de aplicações corporativas.

Essa nova funcionalidade de suporte ao uso de identidades de usuário final para acessar dados é fornecida pela associação de uma instância da funcionalidade Concessões de Acesso do S3 a uma instância do AWS IAM Identity Center. O Centro de Identidade do IAM oferece suporte a provedores de identidades baseados em padrões e é o centro de todos os serviços ou recursos na AWS, incluindo a funcionalidade Concessões de Acesso do S3, que oferecem suporte a identidades de usuário final. O Centro de Identidade do IAM oferece suporte de autenticação para identidades corporativas por meio de seu recurso de propagação de identidades confiáveis. Para obter mais informações, consulte Trusted identity propagation across applications.

Para começar a usar o suporte a identidades da força de trabalho na funcionalidade Concessões de Acesso do S3, como pré-requisito, comece no Centro de Identidade do IAM, configurando o provisionamento de identidades entre um provedor de identidades corporativas e o Centro de Identidade do IAM. O Centro de Identidade do IAM oferece suporte a provedores de identidades corporativas, como Okta, Microsoft Entra ID (antes chamado de Azure Active Directory) ou qualquer outro provedor de identidades (IdP) externo que ofereça suporte ao protocolo SCIM (Sistema de Gerenciamento de Usuários entre Domínios). Quando você conecta o Centro de Identidade do IAM ao IdP e habilita o provisionamento automático, os usuários e grupos do IdP são sincronizados no repositório de identidades do Centro de Identidade do IAM. Após essa etapa, o Centro de Identidade do IAM tem uma visão própria dos usuários e grupos, para que você possa consultá-los usando outros recurso e Serviços da AWS, como a funcionalidade Concessões de Acesso do S3. Para obter mais informações sobre como configurar o provisionamento automático do Centro de Identidade do IAM, consulte Automatic provisioning no Guia do usuário do AWS IAM Identity Center.

O Centro de Identidade do IAM é integrado com o AWS Organizations, o que permite que você gerencie centralmente as permissões em várias Contas da AWS sem configurar cada uma das contas manualmente. Em uma organização típica, o administrador de identidades configura uma instância do Centro de Identidade do IAM para toda a organização, como um único ponto de sincronização de identidades. Essa instância do Centro de Identidade do IAM normalmente é executada em uma Conta da AWS dedicada na organização. Nessa configuração comum, você pode se referir às identidades de usuários e grupos na funcionalidade Concessões de Acesso do S3 de qualquer Conta da AWS na organização.

No entanto, se o administrador do AWS Organizations ainda não configurou uma instância central do Centro de Identidade do IAM, você pode criar uma local na mesma conta da instância da funcionalidade Concessões de Acesso do S3. Essa configuração é mais comum para casos de uso de prova de conceito ou desenvolvimento local. Em todos os casos, a instância do Centro de Identidade do IAM deve estar na mesma Região da AWS que a instância da funcionalidade Concessões de Acesso do S3 à qual será associada.

No diagrama a seguir de uma configuração do Centro de Identidade do IAM com um IdP externo, o IdP é configurado com SCIM para sincronizar o repositório de identidades do IdP com o repositório de identidades no Centro de Identidade do IAM.

Integração do Centro de Identidade do IAM com um repositório de identidades externo por meio de provisionamento automático.

Para usar as identidades de diretório corporativo com a funcionalidade Concessões de Acesso do S3, faça o seguinte:

Como as identidades do diretório podem acessar os dados do S3

Suponha que você tenha usuários do diretório corporativo que precisem acessar os dados do S3 por meio de uma aplicação corporativa, por exemplo, uma aplicação de visualização de documentos, integrada ao IdP externo (por exemplo, Okta) para autenticar usuários. A autenticação do usuário nessas aplicações geralmente é feita por meio de redirecionamentos no navegador da web do usuário. Como os usuários no diretório não são entidades principais do IAM, a aplicação precisa de credenciais do IAM com as quais possa chamar a operação de API GetDataAccess da funcionalidade Concessões de Acesso do S3 para obter credenciais de acesso aos dados do S3 em nome dos usuários. Ao contrário dos usuários e perfis do IAM que recebem credenciais diretamente, a aplicação precisa de uma forma de representar um usuário do diretório, que não está mapeado para um perfil do IAM, para que o usuário possa obter acesso aos dados por meio da funcionalidade Concessões de Acesso do S3.

Essa transição, de usuário de diretório autenticado para um chamador do IAM que pode fazer solicitações à funcionalidade Concessões de Acesso do S3 em nome do usuário do diretório, é feita pela aplicação por meio do recurso de emissor de token confiável do Centro de Identidade do IAM. Depois de autenticar o usuário do diretório, a aplicação tem um token de identidade do IdP (por exemplo, Okta) que representa o usuário do diretório de acordo com Okta. A configuração do emissor de token confiável no Centro de Identidade do IAM permite que a aplicação troque esse token do Okta (o locatário do Okta é configurado como o “emissor confiável”) por outro token de identidade do Centro de Identidade do IAM que representará com segurança o usuário do diretório em Serviços da AWS. A aplicação de dados assumirá um perfil do IAM, fornecendo o token de usuário do diretório do Centro de Identidade do IAM como contexto adicional. A aplicação pode usar a sessão do IAM resultante para chamar a funcionalidade Concessões de Acesso do S3. O token representa tanto a identidade da aplicação (a própria entidade principal do IAM) quanto a identidade do usuário do diretório.

A principal etapa dessa transição é a troca de tokens. A aplicação realiza essa troca de tokens chamando a operação de API CreateTokenWithIAM no Centro de Identidade do IAM. É evidente que isso também é uma chamada de API da AWS e requer que uma entidade principal do IAM a assine. A entidade principal do IAM que faz essa solicitação geralmente é um perfil do IAM associado à aplicação. Por exemplo, se a aplicação é executada no Amazon EC2, a solicitação CreateTokenWithIAM normalmente é executada pelo perfil do IAM associado à instância do EC2 na qual a aplicação é executada. O resultado de uma chamada CreateTokenWithIAM bem-sucedida é um novo token de identidade, que será reconhecido em Serviços da AWS.

A próxima etapa, antes que a aplicação possa chamar GetDataAccess em nome do usuário do diretório, é que a aplicação obtenha uma sessão do IAM que inclua a identidade do usuário do diretório. A aplicação faz isso com uma solicitação AssumeRole do AWS Security Token Service (AWS STS) que também inclui o token do Centro de Identidade do IAM para o usuário do diretório como contexto de identidade adicional. Esse contexto adicional é o que permite que o Centro de Identidade do IAM propague a identidade do usuário do diretório para a próxima etapa. O perfil do IAM que a aplicação assume é o perfil que precisará de permissões do IAM para chamar a operação GetDataAccess.

Tendo assumido o perfil do IAM do portador da identidade com o token do Centro de Identidade do IAM para o usuário do diretório como contexto adicional, a aplicação agora tem tudo o que precisa para fazer uma solicitação GetDataAccess assinada em nome do usuário do diretório autenticado.

A propagação do token se baseia nas seguintes etapas:

Criar uma aplicação do Centro de Identidade do IAM

Primeiro, crie uma aplicação no Centro de Identidade do IAM. Essa aplicação usará um modelo que permite que o Centro de Identidade do IAM identifique quais tipos de configurações de aplicação você pode usar. O comando para criar a aplicação exige que você forneça o nome do recurso da Amazon (ARN) da instância do Centro de Identidade do IAM, um nome de aplicação e o ARN do provedor de aplicações. O provedor de aplicações é o provedor SAML ou OAuth que a aplicação usará para fazer chamadas ao Centro de Identidade do IAM.

Para usar o comando a seguir, substitua os user input placeholders por suas próprias informações:

aws sso-admin create-application \
 --instance-arn "arn:aws:sso:::instance/ssoins-ssoins-1234567890abcdef" \
 --application-provider-arn "arn:aws:sso::aws:applicationProvider/custom" \
 --name MyDataApplication

Resposta:

{
   "ApplicationArn": "arn:aws:sso::123456789012:application/ssoins-ssoins-1234567890abcdef/apl-abcd1234a1b2c3d"
}

Criar um emissor de token confiável

Agora que você tem uma aplicação do Centro de Identidade do IAM, a próxima etapa é configurar um emissor de token confiável que será usado para trocar os valores de IdToken do IdP por tokens do Centro de Identidade do IAM. Nesta etapa, você precisa fornecer os seguintes itens:

  • O URL do emissor do provedor de identidades

  • O nome do emissor de token confiável

  • O caminho do atributo de reivindicação

  • O caminho do atributo do repositório de identidades

  • A opção de recuperação do JSON Web Key Set (JWKS)

O caminho do atributo de reivindicação é o atributo do provedor de identidades que será usado para mapear o atributo do repositório de identidades. Normalmente, o caminho do atributo de reivindicação é o endereço de e-mail do usuário, mas você pode usar outros atributos para realizar o mapeamento.

Crie um arquivo chamado oidc-configuration.json com o texto a seguir. Para usar esse arquivo, substitua os user input placeholders por suas próprias informações.

{
  "OidcJwtConfiguration":
     {
      "IssuerUrl": "https://login.microsoftonline.com/a1b2c3d4-abcd-1234-b7d5-b154440ac123/v2.0",
      "ClaimAttributePath": "preferred_username",
      "IdentityStoreAttributePath": "userName",
      "JwksRetrievalOption": "OPEN_ID_DISCOVERY"
     }
}

Para criar o emissor de token confiável, execute o comando a seguir. Para usar esse exemplo de comando, substitua os user input placeholders por suas próprias informações.

aws sso-admin create-trusted-token-issuer \
  --instance-arn "arn:aws:sso:::instance/ssoins-1234567890abcdef" \
  --name MyEntraIDTrustedIssuer \
  --trusted-token-issuer-type OIDC_JWT \
  --trusted-token-issuer-configuration file://./oidc-configuration.json

Resposta

{
  "TrustedTokenIssuerArn": "arn:aws:sso::123456789012:trustedTokenIssuer/ssoins-1234567890abcdef/tti-43b4a822-1234-1234-1234-a1b2c3d41234"
}

Conectar a aplicação do Centro de Identidade do IAM ao emissor de token confiável

O emissor de token confiável precisa de mais algumas configurações para funcionar. Defina o público em que o emissor de token confiável confiará. O público é o valor dentro do IdToken que é identificado pela chave e pode ser encontrado nas configurações do provedor de identidades. Por exemplo: 

1234973b-abcd-1234-abcd-345c5a9c1234

Crie um arquivo chamado grant.json com o conteúdo a seguir. Para usar esse arquivo, altere o público para que corresponda às configurações do seu provedor de identidades e forneça o ARN do emissor de token confiável que foi retornado pelo comando anterior.

{
   "JwtBearer":
     {
       "AuthorizedTokenIssuers":
         [
           {
             "TrustedTokenIssuerArn": "arn:aws:sso::123456789012:trustedTokenIssuer/ssoins-1234567890abcdef/tti-43b4a822-1234-1234-1234-a1b2c3d41234",
               "AuthorizedAudiences":
                 [
                   "1234973b-abcd-1234-abcd-345c5a9c1234"
                 ]
            }
         ]
     }
 }

Execute o exemplo de comando a seguir. Para usar esse comando, substitua user input placeholders por suas informações.

aws sso-admin put-application-grant \
  --application-arn "arn:aws:sso::123456789012:application/ssoins-ssoins-1234567890abcdef/apl-abcd1234a1b2c3d" \
  --grant-type "urn:ietf:params:oauth:grant-type:jwt-bearer" \
  --grant file://./grant.json \

Esse comando define o emissor de token confiável com configurações para confiar no público do arquivo grant.json e vincular esse público à aplicação criada na primeira etapa para a troca de tokens do tipo jwt-bearer. A string urn:ietf:params:oauth:grant-type:jwt-bearer não é uma string arbitrária. É um namespace registrado nos perfis de declaração de JSON Web Token (JWT) OAuth. Você pode encontrar mais informações sobre esse namespace em RFC 7523.

Depois, use o comando a seguir para configurar quais escopos o emissor de token confiável incluirá ao trocar valores de IdToken do seu provedor de identidades. Para a funcionalidade Concessões de Acesso do S3, o valor do parâmetro --scope é s3:access_grants:read_write.

aws sso-admin put-application-access-scope \
  --application-arn "arn:aws:sso::111122223333:application/ssoins-ssoins-111122223333abcdef/apl-abcd1234a1b2c3d" \
  --scope "s3:access_grants:read_write"

A última etapa é anexar uma política de recursos à aplicação do Centro de Identidade do IAM. Essa política permitirá que o perfil do IAM da aplicação faça solicitações para a operação de API sso-oauth:CreateTokenWithIAM e receba os valores de IdToken do Centro de Identidade do IAM.

Crie um arquivo chamado authentication-method.json com o conteúdo a seguir. Substitua 123456789012 pelo ID da sua conta.

{
   "Iam":
       {
         "ActorPolicy":
             {
                "Version": "2012-10-17",
                    "Statement":
                    [
                        {
                           "Effect": "Allow",
                            "Principal":
                            {
                              "AWS": "arn:aws:iam::123456789012:role/webapp"
                            },
                           "Action": "sso-oauth:CreateTokenWithIAM",
                            "Resource": "*"
                        }
                    ]
                }
            }
        }

Para anexar a política à aplicação do Centro de Identidade do IAM, execute o seguinte comando:

aws sso-admin put-application-authentication-method \
   --application-arn "arn:aws:sso::123456789012:application/ssoins-ssoins-1234567890abcdef/apl-abcd1234a1b2c3d" \
   --authentication-method-type IAM \
   --authentication-method file://./authentication-method.json

Isso conclui as configurações para usar a funcionalidade Concessões de Acesso do S3 com usuários de diretório por meio de uma aplicação web. Você pode testar essa configuração diretamente na aplicação ou chamar a operação de API CreateTokenWithIAM usando o seguinte comando de um perfil do IAM permitido na política da aplicação do Centro de Identidade do IAM:

aws sso-oidc create-token-with-iam \
   --client-id "arn:aws:sso::123456789012:application/ssoins-ssoins-1234567890abcdef/apl-abcd1234a1b2c3d"  \
   --grant-type urn:ietf:params:oauth:grant-type:jwt-bearer \
   --assertion IdToken

A resposta será semelhante a esta:

{
    "accessToken": "<suppressed long string to reduce space>",
    "tokenType": "Bearer",
    "expiresIn": 3600,
    "refreshToken": "<suppressed long string to reduce space>",
    "idToken": "<suppressed long string to reduce space>",
    "issuedTokenType": "urn:ietf:params:oauth:token-type:refresh_token",
    "scope": [
      "sts:identity_context",
      "s3:access_grants:read_write",
      "openid",
      "aws"
    ]
}

Se você decodificar o valor de IdToken que está codificado com base64, poderá ver os pares de valor e chave no formato JSON. A chave sts:identity_context contém o valor que a aplicação precisa enviar na solicitação sts:AssumeRole para incluir as informações de identidade do usuário do diretório. Veja a seguir um exemplo do IdToken decodificado:

{
    "aws:identity_store_id": "d-996773e796",
    "sts:identity_context": "AQoJb3JpZ2luX2VjEOTtl;<SUPRESSED>",
    "sub": "83d43802-00b1-7054-db02-f1d683aacba5",
    "aws:instance_account": "123456789012",
    "iss": "https://identitycenter.amazonaws.com/ssoins-1234567890abcdef",
    "sts:audit_context": "AQoJb3JpZ2luX2VjEOT<SUPRESSED>==",
    "aws:identity_store_arn": "arn:aws:identitystore::232642235904:identitystore/d-996773e796",
    "aud": "abcd12344U0gi7n4Yyp0-WV1LWNlbnRyYWwtMQ",
    "aws:instance_arn": "arn:aws:sso:::instance/ssoins-6987d7fb04cf7a51",
    "aws:credential_id": "EXAMPLEHI5glPh40y9TpApJn8...",
    "act": {
       "sub": "arn:aws:sso::232642235904:trustedTokenIssuer/ssoins-6987d7fb04cf7a51/43b4a822-1020-7053-3631-cb2d3e28d10e"
    },
    "auth_time": "2023-11-01T20:24:28Z",
    "exp": 1698873868,
    "iat": 1698870268
}

Você pode obter o valor de sts:identity_context e enviar essas informações em uma chamada de sts:AssumeRole. Veja a seguir um exemplo da sintaxe na CLI. O perfil a ser assumido é um perfil temporário com permissões para invocar s3:GetDataAccess.

aws sts assume-role \
   --role-arn "arn:aws:iam::123456789012:role/temp-role" \
   --role-session-name "TempDirectoryUserRole" \
   --provided-contexts ProviderArn="arn:aws:iam::aws:contextProvider/IdentityCenter",ContextAssertion="value from sts:identity_context"

Agora você pode usar as credenciais recebidas dessa chamada para invocar a operação de API s3:GetDataAccess e receber as credenciais finais com acesso aos recursos do S3.