Identificar usuários com a federação OIDC - AWS Identity and Access Management

Identificar usuários com a federação OIDC

Quando você cria políticas de acesso no IAM, geralmente é útil poder especificar permissões com base em aplicações configuradas e no ID de usuários que se autenticaram usando um provedor de identidade (IdP) externo. Por exemplo, sua aplicação móvel que usa a federação OIDC pode manter as informações no Amazon S3 usando uma estrutura como esta:

myBucket/app1/user1 myBucket/app1/user2 myBucket/app1/user3 ... myBucket/app2/user1 myBucket/app2/user2 myBucket/app2/user3 ...

Além disso, você pode distinguir esses caminhos por provedor. Neste caso, a estrutura pode se parecer com a seguinte (apenas dois provedores são listados para economizar espaço):

myBucket/Amazon/app1/user1 myBucket/Amazon/app1/user2 myBucket/Amazon/app1/user3 ... myBucket/Amazon/app2/user1 myBucket/Amazon/app2/user2 myBucket/Amazon/app2/user3 myBucket/Facebook/app1/user1 myBucket/Facebook/app1/user2 myBucket/Facebook/app1/user3 ... myBucket/Facebook/app2/user1 myBucket/Facebook/app2/user2 myBucket/Facebook/app2/user3 ...

Para essas estruturas, app1 e app2 representam aplicativos diferentes, como jogos diferentes e cada usuário do aplicativo tem uma pasta diferente. Os valores para app1 e app2 podem ser nomes acessíveis que você atribui (por exemplo, mynumbersgame) ou podem ser os IDs de aplicativos que os provedores atribuem quando você configura o aplicativo. Se você incluir nomes de provedor no caminho, eles também poderão ser nomes acessíveis, como Cognito, Amazon, Facebooke Google.

Normalmente, você pode criar as pastas para app1 e app2 por meio do AWS Management Console, já que os nomes de aplicativos são valores estáticos. Isso também se aplica se você incluir o nome do provedor no caminho, já que o nome do provedor também é um valor estático. Em contraste, as pastas específicas do usuário (user1, user2, user3 etc.) devem ser criadas em tempo de execução do aplicativo, usando o ID do usuário disponível no valor SubjectFromWebIdentityToken retornado pela solicitação para AssumeRoleWithWebIdentity.

Para gravar políticas que permitam acesso exclusivo aos recursos para usuários individuais, você pode combinar o nome da pasta, incluindo o nome do aplicativo e o nome do provedor, se estiver usando-o. Inclua as seguintes chaves de contexto específicas do provedor que fazem referência ao ID do usuário que o provedor retorna:

  • cognito-identity.amazonaws.com:sub

  • www.amazon.com:user_id

  • graph.facebook.com:id

  • accounts.google.com:sub

Para provedores OIDC, use a URL totalmente qualificada do provedor OIDC com a chave de subcontexto, como o seguinte exemplo:

  • server.example.com:sub

O exemplo a seguir mostra uma política de permissões que concede acesso a um bucket no Amazon S3 somente se o prefixo para o bucket corresponder à string:

myBucket/Amazon/mynumbersgame/user1

O exemplo supõe que o usuário faz login usando o Login with Amazon e que o usuário usa uma aplicação chamada mynumbersgame. O ID exclusivo do usuário é apresentado como um atributo chamado user_id.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::myBucket"], "Condition": {"StringLike": {"s3:prefix": ["Amazon/mynumbersgame/${www.amazon.com:user_id}/*"]}} }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::myBucket/amazon/mynumbersgame/${www.amazon.com:user_id}", "arn:aws:s3:::myBucket/amazon/mynumbersgame/${www.amazon.com:user_id}/*" ] } ] }

Você criaria políticas semelhantes para usuários que fazem login usando o Amazon Cognito, Facebook, Google ou outro IdP compatível com OpenID Connect. Essas políticas usariam um nome de provedor diferente como parte do caminho, bem como IDs de aplicativo diferentes.

Para obter mais informações sobre chaves de federação OIDC disponíveis para verificação de condições nas políticas, consulte Chaves disponíveis para federação OIDC da AWS.