Permisos para GetFederationToken

Un usuario de IAM llama a la operación GetFederationToken y devuelve credenciales temporales para ese usuario. Esta operación federa al usuario. Los permisos asignados a un usuario federado están definidos en dos lugares:

• Las políticas de sesión que se pasan como parámetro en la llamada a la API GetFederationToken. (Este es el caso más frecuente).

• Una política basada en recursos que nombra explícitamente al usuario federado en el elemento Principal de la política. (Este es el caso menos frecuente).

Las políticas de sesión son políticas avanzadas que se pasan como parámetros cuando se crea una sesión temporal mediante programación. Al crear una sesión de usuario federado y pasar las políticas de sesión, los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades del usuario de y las políticas de la sesión. No puede utilizar la política de sesión para conceder más permisos que los permitidos por la política basada en identidades del usuario que se federa.

En la mayoría de los casos, si no transfiere una política con la llamada a la API GetFederationToken, las credenciales de seguridad temporales obtenidas no tendrán permisos. Sin embargo, una política basada en recursos puede proporcionar permisos adicionales para la sesión. Puede acceder a un recurso con una política basada en recursos que especifica la sesión como el principal permitido.

Las figuras siguientes muestran una representación visual de cómo las políticas interactúan para determinar los permisos de las credenciales de seguridad temporales devueltos por una llamada a GetFederationToken.

Ejemplo: asignación de permisos con GetFederationToken

Puede utilizar la acción de la API GetFederationToken con diferentes tipos de políticas. A continuación se ofrecen algunos ejemplos.

Política asociada al usuario de IAM

En este ejemplo, tiene una aplicación cliente basada en navegador que se utiliza dos servicios web de backend. Un servicio de backend es su propio servidor de autenticación, que utiliza su propio sistema de identidad para autenticar la aplicación de cliente. El otro servicio de backend es un servicio de AWS que proporciona algunas de las funcionalidades de la aplicación cliente. Su servidor autentica la aplicación cliente y crea o recupera la política de permisos correspondiente. A continuación, llama a la API GetFederationToken para obtener credenciales de seguridad temporales y devuelve dichas credenciales a la aplicación cliente. Esta puede realizar solicitudes directamente al servicio de AWS con las credenciales de seguridad temporales. Esta arquitectura permite a la aplicación cliente realizar solicitudes de AWS sin integrar credenciales de AWS a largo plazo.

El servidor de autenticación llama a la API de GetFederationToken con las credenciales de seguridad a largo plazo de un usuario IAM llamado token-app. Sin embargo, las credenciales de usuario de IAM a largo plazo permanecen en el servidor y nunca se distribuyen al cliente. La política del ejemplo siguiente está asociada al usuario de IAM token-app y define el conjunto más amplio de permisos que sus usuarios federados (clientes) necesitarán. Tenga en cuenta que el permiso sts:GetFederationToken es obligatorio para que su servicio de autenticación obtenga credenciales de seguridad temporales para los usuarios federados.

nota

AWS proporciona una aplicación Java de muestra para este fin; la puede descargar aquí: Token Vending Machine for Identity Registration - Sample Java Web Application.

ejemplo Ejemplo de política asociada al usuario de IAM token-app que llama a GetFederationToken

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListTables",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sqs:ReceiveMessage",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sns:ListSubscriptions",
      "Resource": "*"
    }
  ]
}

La política anterior concede varios permisos al usuario de IAM. Sin embargo, esta política por sí sola no concede ningún permiso al usuario federado. Si este usuario de IAM llama a GetFederationToken y no transfiere una política como parámetro de la llamada a la API, el usuario federado obtenido no tendrá permisos efectivos.

Política de sesión pasada como parámetro

La forma más frecuente de asegurarse de que se le asigne al usuario federado el permiso adecuado consiste en pasar políticas de sesión en la llamada a la API GetFederationToken. Profundizando en el ejemplo anterior, supongamos que GetFederationToken se llama con las credenciales del usuario de IAM token-app. Entonces, imagine que las siguientes políticas de sesión se transfieren como parámetro de la llamada a la API. El usuario federado resultante tiene permiso para crear una lista del contenido del bucket de Amazon S3 denominado productionapp. El usuario no puede realizar las acciones de Amazon S3 GetObject, PutObject, y DeleteObject en elementos del bucket productionapp.

Estos permisos se asignan al usuario federado porque son la intersección de las políticas del usuario de IAM y las políticas de la sesión que transfiere.

El usuario federado no podrá realizar acciones en Amazon SNS, Amazon SQS, Amazon DynamoDB, ni en ningún bucket de S3, excepto productionapp. Estas acciones se deniegan a pesar de que el usuario de IAM asociado a la llamada a GetFederationToken cuenta con los permisos correspondientes.

ejemplo Ejemplo de política de sesión transferida como parámetro de la llamada a la API GetFederationToken.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::productionapp"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::productionapp/*"]
    }
  ]
}

Políticas basadas en recursos

Algunos recursos de AWS admiten políticas basadas en recursos, y dichas políticas proporcionan otro mecanismo para conceder permisos directamente a un usuario federado. Solo algunos servicios de AWS admiten políticas basadas en recursos. Por ejemplo, Amazon S3 tiene buckets, Amazon SNS tiene temas y Amazon SQS tiene colas a las que puede asociar políticas. Para obtener una lista de todos los servicios que admiten políticas basadas en recursos, consulte Servicios de AWS que funcionan con IAM y observe la columna de políticas basadas en recursos de las tablas. Puede utilizar políticas basadas en recursos para asignar permisos directamente a un usuario federado. Para ello, debe especificar el Nombre de recurso de Amazon (ARN) del usuario federado en el elemento Principal de la política basada en recursos El siguiente ejemplo ilustra esto y amplía los ejemplos anteriores, utilizando un bucket de S3 denominado productionapp.

La política basada en recursos siguiente se asocia al bucket. Esta política del bucket permite a una usuaria federada llamada Carol obtener acceso al bucket. Cuando la política de ejemplo descrita anteriormente se asocia al usuario de IAM token-app, la usuaria federada Carol tiene permiso para realizar las accioness3:GetObject, s3:PutObject, y s3:DeleteObject en el bucket denominado productionapp. Esto es válido incluso cuando no se pasa ninguna política de sesión como parámetro en la llamada a la API GetFederationToken. En este caso, la explicación radica en que la siguiente política basada en recursos ha concedido permisos explícitos a la usuaria federada denominada Carol.

Recuerde, solo se conceden permisos a un usuario federado cuando estos se conceden de forma explícita al usuario de IAM y al usuario federado. También se pueden conceder (dentro de la cuenta) mediante una política basada en recursos que nombre explícitamente al usuario federado en el elemento Principal de la política, como en el siguiente ejemplo.

ejemplo Ejemplo de política de bucket que permite el acceso a un usuario federado

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "arn:aws:sts::account-id:federated-user/Carol"},
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::productionapp/*"]
  }
}

Para obtener más información sobre cómo se evalúan las políticas, consulte Policy evaluation logic (Lógica de evaluación de las políticas).