

# Permisos para GetFederationToken
<a name="id_credentials_temp_control-access_getfederationtoken"></a>

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 una sesión de usuario federado de AWS STS se definen en uno de los siguientes 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 la sesión de usuario federado de AWS STS 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 de AWS STS y transmitir políticas de sesión, los permisos de la sesión resultante son la intersección entre la política basada en identidades del usuario y las políticas de 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`.

![\[Usuario de IAM: las siguientes ilustraciones muestran marcas de verificación para indicar que los permisos de sesión son la intersección entre la política basada en identidades del usuario y las políticas de sesión. Los permisos de sesión también pueden ser la intersección de las políticas basadas en identidades del usuario y las políticas basadas en recursos.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)


## Ejemplo: asignación de permisos con GetFederationToken
<a name="permissions-get-federation-token-example"></a>

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
<a name="permissions-get-federation-token-example-iam-user"></a>

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 siguiente política de ejemplo se asocia al usuario de IAM `token-app` y define el conjunto más amplio de permisos que necesitarán los usuarios federados de AWS STS (clientes). Tenga en cuenta que se requiere el permiso `sts:GetFederationToken` para que el servicio de autenticación obtenga credenciales de seguridad temporales para los usuarios federados de AWS STS.

**Example 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 de AWS STS. 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 de AWS STS obtenido no tendrá permisos efectivos. 

### Política de sesión pasada como parámetro
<a name="permissions-get-federation-token-example-passed-policy"></a>

La manera más habitual de asegurarse de que al usuario federado de AWS STS se le asignen los permisos adecuados es incluir 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 de AWS STS resultante tiene permiso para enumerar el 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 de AWS STS no pudo realizar acciones en Amazon SNS, Amazon SQS, Amazon DynamoDB ni en ningún bucket de S3, excepto en `productionapp`. Estas acciones se deniegan a pesar de que el usuario de IAM asociado a la llamada a `GetFederationToken` cuenta con los permisos correspondientes.

**Example 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
<a name="permissions-get-federation-token-resource-based-policy"></a>

Algunos recursos de AWS permiten el uso de políticas basadas en recursos, las cuales ofrecen un mecanismo adicional para conceder permisos directamente a un usuario federado de AWS STS. 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](reference_aws-services-that-work-with-iam.md) 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 de AWS STS. Para ello, debe especificar el Nombre de recurso de Amazon (ARN) del usuario federado de AWS STS 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 de AWS STS 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 de AWS STS, llamada Carol, tiene permiso para realizar las acciones `s3: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 de AWS STS denominada Carol. 

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

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

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Principal": {
            "AWS": "arn:aws:sts::111122223333: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](reference_policies_evaluation-logic.md) (Lógica de evaluación de las políticas).