# Escenarios habituales en los roles de IAM
Al igual que sucede con la mayoría de las características de AWS, hay dos formas de utilizar un rol: de forma interactiva en la consola de IAM o con programas, con la AWS CLI, Tools for Windows PowerShell o la API.
+ Los usuarios de IAM de su cuenta que usan la consola de IAM pueden *cambiar a* un rol para utilizar temporalmente los permisos del rol en la consola. Los usuarios renuncian a sus permisos originales y adoptan los permisos asignados al rol. Cuando el usuario deja de utilizar el rol, sus permisos originales se restablecen.
+ Una aplicación o un servicio que AWS ofrece (como Amazon EC2) puede *asumir* un rol solicitando credenciales de seguridad temporales para un rol con el que realizar solicitudes programadas a AWS. Un rol se utiliza de este modo para no tener que compartir ni mantener credenciales de seguridad a largo plazo (por ejemplo, mediante la creación de un usuario de IAM) para todas las entidades que requieran acceso a un recurso.
**nota**
Esta guía utiliza las frases *cambiar a un rol* y *asumir un rol* indistintamente.
La forma más sencilla de utilizar roles consiste en conceder a los usuarios de IAM permisos para cambiar a los roles que usted crea dentro de su propia Cuenta de AWS o en otra. De esta forma, pueden cambiar de roles con facilidad utilizando la consola de IAM para utilizar permisos que usted no quiere que tengan normalmente y salir de los roles para renunciar a los permisos. Esto es útil para evitar el acceso *accidental* a recursos confidenciales o su modificación.
Para informarse de los usos de roles más complejos, como la concesión de acceso a aplicaciones y servicios, o a usuarios externos federados, puede llamar a la API `AssumeRole`. Esta llamada a la API devuelve un conjunto de credenciales temporales que la aplicación puede utilizar en las llamadas a la API posteriores. Las acciones que se intenten efectuar con las credenciales temporales solo tienen los permisos que el rol asociado les concede. Una aplicación no tiene que "salir" del rol de la misma forma que lo hace un usuario en la consola; en su lugar, la aplicación simplemente deja de utilizar las credenciales temporales y vuelve a realizar llamadas con las credenciales originales.
Los usuarios federados inician sesión con las credenciales de un proveedor de identidades (IdP). A continuación, AWS proporciona credenciales temporales al proveedor de identidades de confianza para que las transmita al usuario y que este las incluya en las solicitudes de recursos de AWS posteriores. Estas credenciales proporcionan los permisos concedidos al rol asignado.
En esta sección se proporciona información general sobre las situaciones siguientes:
+ [Proporcionar a un usuario de IAM de una Cuenta de AWS propia acceso a recursos de otra cuenta propia](id_roles_common-scenarios_aws-accounts.md)
+ [Proporcionar acceso a cargas de trabajo ajenas a AWS](id_roles_common-scenarios_non-aws.md)
+ [Proporcionar acceso a usuarios de IAM de Cuentas de AWS que le pertenezcan a terceros](id_roles_common-scenarios_third-party.md)
+ [Proporcionar acceso a servicios ofrecidos por AWS a recursos de AWS](id_roles_common-scenarios_services.md)
+ [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](id_roles_common-scenarios_federated-users.md)
# Acceso para un usuario de IAM en otra Cuenta de AWS propia
Puede conceder a los usuarios de IAM permiso para cambiar de roles en su Cuenta de AWS o a los roles definidos en otras Cuentas de AWS propias.
**nota**
Si desea conceder acceso a una cuenta de la que no es propietario o no tiene control, consulte [Acceder a las Cuentas de AWS que le pertenezcan a terceros](id_roles_common-scenarios_third-party.md) más adelante en este tema.
Imagine que dispone de instancias de Amazon EC2 que son de vital importancia para su organización. En lugar de conceder directamente permiso a los usuarios para finalizar las instancias, puede crear un rol con estos privilegios. A continuación, permita que los administradores cambien de rol cuando necesiten terminar una instancia. Al hacer esto, se añaden las siguientes capas de protección a las instancias:
+ Debe conceder explícitamente permiso a los usuarios para asumir el rol.
+ Los usuarios deben cambiar de rol de forma activa con la Consola de administración de AWS o asumir el rol utilizando la AWS CLI o la API de AWS.
+ Puede añadir una protección Multi-Factor Authentication (MFA) al rol para que únicamente los usuarios que inicien sesión con un dispositivo MFA puedan asumir el rol. Para obtener información sobre cómo configurar un rol para que los usuarios que lo asuman deban primero autenticarse mediante la autenticación multifactor (MFA), consulte [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md).
Recomendamos utilizar este enfoque para aplicar el *principio de privilegio mínimo*. Esto significa limitar el uso de permisos elevados únicamente cuando sean necesarios para realizar tareas específicas. Con los roles puede ayudar a impedir cambios accidentales en entornos confidenciales, especialmente si los combina con un proceso de [auditoría](cloudtrail-integration.md) con el fin de garantizar que los roles solo se utilizan cuando sean necesarios.
Al crear un rol con este fin, debe especificar las cuentas mediante el ID cuyos usuarios necesitan obtener acceso en el elemento `Principal` de la política de confianza del rol. Puede conceder permisos a usuarios específicos de estas otras cuentas para cambiar de rol. Consulte [¿Qué es IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles.
Un usuario de una cuenta puede cambiar de rol en la misma cuenta o en una cuenta diferente. Al utilizar el rol, el usuario solo puede realizar las acciones y obtener acceso únicamente a los recursos permitidos por el rol; sus permisos originales de usuario se suspenden. Si el usuario deja de utilizar el rol, sus permisos originales se restablecen.
## Situación de ejemplo en la que se usan cuentas de desarrollo y producción separadas
Imagine que la organización tiene varias Cuentas de AWS para aislar su entorno de desarrollo del de producción. Los usuarios de la cuenta de desarrollo podrían necesitar ocasionalmente acceder a los recursos en la cuenta de producción. Por ejemplo, es posible que necesite el acceso entre cuentas al promocionar una actualización desde el entorno de desarrollo al entorno de producción. Aunque podría crear identidades distintas (y contraseñas) para los usuarios que trabajan en las dos cuentas, la administración de credenciales de varias cuentas dificulta la administración de las identidades. En la siguiente figura, todos los usuarios se administran en la cuenta de desarrollo, pero algunos desarrolladores exigen acceso limitado a la cuenta de producción. La cuenta de desarrollo tiene dos grupos: Evaluadores y Desarrolladores, y cada grupo tiene su propia política.
![\[Utilice un rol para delegar permisos a un usuario en otra cuenta\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. En la cuenta de producción un administrador utiliza IAM para crear el rol `UpdateApp` en dicha cuenta. En el rol, el administrador define una política de confianza que especifica la cuenta de desarrollo como `Principal`, lo que significa que los usuarios autorizados de la cuenta de desarrollo pueden utilizar el rol `UpdateApp`. El administrador también define una política de permisos para el rol que especifica los permisos de lectura y escritura del bucket de Amazon S3 denominado `productionapp`.
El administrador comparte entonces la información pertinente con cualquier usuario que necesite asumir el rol. Dicha información es el número de cuenta y el nombre del rol (para usuarios de la consola de AWS) o el Nombre de recurso de Amazon (ARN) (para acceso de API de AWS CLI o AWS). El ARN del rol podría parecerse a `arn:aws:iam::123456789012:role/UpdateApp`, donde el rol se denomina `UpdateApp` y el rol se creó en el número de cuenta 123456789012.
**nota**
El administrador puede configurar de forma opcional el rol para que los usuarios que lo asuman deban primero autenticarse mediante la opción Multi-Factor Authentication (MFA). Para obtener más información, consulte [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md).
1. En la cuenta de desarrollo un administrador concede a los miembros del grupo Desarrolladores permiso para cambiar de rol. Esto se realiza mediante la concesión de permiso al grupo Desarrolladores para llamar a la API AWS Security Token Service de AWS STS (`AssumeRole`) para el rol `UpdateApp`. Cualquier usuario de IAM que pertenezca al grupo Desarrolladores de la cuenta de desarrollo ahora puede cambiar al rol `UpdateApp` en la cuenta de producción. Otros usuarios que no están en el grupo Desarrolladores no tienen permiso para cambiar de rol y, por lo tanto, no pueden obtener acceso al bucket de S3 en la cuenta de producción.
1. El usuario solicita cambios de rol:
+ Consola de AWS: el usuario selecciona el nombre de la cuenta en la barra de navegación y elige **Switch Role (Cambiar rol)**. El usuario especifica el ID de la cuenta (o alias) y el nombre del rol. O bien, el usuario puede hacer clic en un enlace enviado por correo electrónico enviado por el administrador. Este enlace redirigirá al usuario a la página **Switch Role (Cambiar rol)** con los detalles ya completados.
+ API de AWS/AWS CLI: un usuario del grupo Desarrolladores de la cuenta de desarrollo llama a la función `AssumeRole` para obtener las credenciales para el rol `UpdateApp`. El usuario especifica el ARN del rol `UpdateApp` como parte de la llamada. Si un usuario del grupo Evaluadores realiza la misma solicitud, esta no podrá llevarse a cabo, ya que los evaluadores no tienen permiso para llamar a `AssumeRole` para solicitar el ARN del rol `UpdateApp`.
1. AWS STS devuelve credenciales temporales:
+ Consola de AWS: AWS STS verifica la solicitud con la política de confianza del rol para garantizar que la solicitud procede de una entidad de confianza (es decir, la cuenta de desarrollo). Tras realizar la verificación, AWS STS devuelve [credenciales de seguridad temporales ](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) a la consola de AWS.
+ API/CLI: AWS STS verifica la solicitud con la política de confianza del rol para garantizar que la solicitud procede de una entidad de confianza (es decir, la cuenta de desarrollo). Tras realizar la verificación, AWS STS devuelve [credenciales de seguridad temporales](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) a la aplicación.
1. Las credenciales temporales permiten el acceso a los recursos de AWS:
+ Consola de AWS: la consola de AWS utiliza las credenciales temporales en nombre del usuario para todas las acciones de consola posteriores, en este caso, para leer y escribir en el bucket `productionapp`. La consola no puede obtener acceso a cualquier otro recurso en la cuenta de producción. Si el usuario deja de utilizar el rol, los permisos del usuario vuelven a los permisos originales antes de cambiar de rol.
+ API/CLI: la aplicación utiliza las credenciales de seguridad temporales para actualizar el bucket de `productionapp`. Con las credenciales de seguridad temporales, la aplicación solo puede leer y escribir en el bucket de `productionapp` y no puede obtener acceso a cualquier otro recurso en la cuenta de producción. La aplicación no tiene que dejar de utilizar el rol, sino que, en cambio, deja de utilizar las credenciales temporales y utiliza las credenciales originales en las llamadas API posteriores.
## Recursos adicionales
Para obtener más información, consulte los siguientes temas:
+ [Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM](tutorial_cross-account-with-roles.md)
# Acceso para cargas de trabajo que no sean de AWS
Un [rol de IAM](id_roles.md) es un objeto de AWS Identity and Access Management (IAM) al que se le asignan [permisos](access_policies.md). Cuando se [asume ese rol](id_roles_manage-assume.md) mediante una identidad de IAM o una identidad externa a AWS, proporciona credenciales de seguridad temporales para la sesión de rol. Es posible que tenga cargas de trabajo ejecutándose en un centro de datos u otra infraestructura fuera de AWS que deban acceder a los recursos de AWS. En lugar de crear, distribuir y administrar claves de acceso de larga duración, puede utilizar AWS Identity and Access Management Roles Anywhere (IAM Roles Anywhere) para autenticar las cargas de trabajo ajenas a AWS. IAM Roles Anywhere utiliza certificados X.509 de la entidad de certificación (CA) para autenticar identidades y proporcionar acceso seguro a Servicios de AWS con las credenciales temporales proporcionadas por un rol de IAM.
**Para utilizar IAM Roles Anywhere**
1. Configure una CA mediante [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html), o bien utilice una CA de su propia infraestructura de PKI.
1. Después de configurar una CA, debe crear un objeto en IAM Roles Anywhere denominado *anclaje de confianza*. Este anclaje establece la confianza entre IAM Roles Anywhere y su CA para la autenticación.
1. A continuación, puede configurar los roles de IAM existentes o crear otros nuevos que confíen en el servicio de IAM Roles Anywhere.
1. Autentique las cargas de trabajo que no sean de AWS con IAM Roles Anywhere mediante el anclaje de veracidad. AWS concede a la carga de trabajo que no es de AWS credenciales temporales para el rol de IAM que tiene acceso a sus recursos de AWS.
## Recursos adicionales
Los siguientes recursos pueden ayudarlo a obtener más información sobre cómo proporcionar acceso a las cargas de trabajo que no son de AWS.
+ Para obtener más información sobre cómo configurar IAM Roles Anywhere, consulte [Qué es AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) en la *Guía del usuario de IAM Roles Anywhere*.
+ A fin de obtener información sobre cómo configurar una infraestructura de clave pública (PKI) para IAM Roles Anywhere, consulte [IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/) en el *Blog de seguridad de AWS*.
# Acceder a las Cuentas de AWS que le pertenezcan a terceros
Cuando terceros necesitan obtener acceso a recursos de AWS de su organización, puede utilizar roles para delegarles el acceso. Por ejemplo, puede que un tercero proporcione un servicio de administración de sus recursos de AWS. Con los roles de IAM, puede concederle acceso a sus recursos de AWS a terceros sin tener que compartir sus credenciales de seguridad de AWS. En vez de ello, el tercero puede obtener acceso a sus recursos de AWS asumiendo un rol que usted crea en su Cuenta de AWS. Consulte [¿Qué es IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles.
Los terceros deben proporcionarle la siguiente información para que pueda crear un rol que puedan asumir:
+ **El ID de Cuenta de AWS del tercero**. Especifique su ID de Cuenta de AWS como entidad principal cuando defina la política de confianza del rol.
+ **Un ID externo para la asociación exclusiva con el rol**. El ID externo puede ser cualquier identificador secreto que usted y el tercero conozcan. Por ejemplo, puede utilizar un ID de factura entre usted y el tercero, pero no utilice nada que pueda adivinarse, como el nombre o el número de teléfono del tercero. Debe especificar este ID cuando defina la política de confianza del rol. El tercero debe proporcionar este ID cuando asuma el rol.
+ **Los permisos que el tercero necesita para poder trabajar con sus recursos de AWS**. Debe especificar estos permisos cuando defina la política de permisos del rol. Esta política define qué acciones pueden ejecutar y a qué recursos pueden obtener acceso.
Después de crear el rol, debe proporcionar el nombre de recurso de Amazon (ARN) del rol al tercero. El ARN del rol es necesario para asumir el rol.
**importante**
Cuando concede acceso a terceros a sus recursos de AWS, estos pueden obtener acceso a cualquier recurso que especifique en la política. El uso que efectúen de sus recursos se le facturará a usted. Asegúrese de que limita el uso de los recursos de forma adecuada.
## ID externos para el acceso de terceros
Un ID externo permite al usuario que asume el rol afirmar las circunstancias en las que opera. También ofrece al propietario de la cuenta una forma de permitir asumir el rol únicamente en circunstancias específicas. La función principal del ID externo es abordar y prevenir [El problema del suplente confuso](confused-deputy.md).
**importante**
AWS no trate el ID externo como un secreto. Después de crear un secreto como un par de claves de acceso o una contraseña en AWS, no puede verlos de nuevo. Cualquier usuario con permiso para ver el rol puede ver el ID externo de dicho rol.
## ¿Cuándo debería utilizar un ID externo?
Utilice un ID externo en las siguientes situaciones:
+ Es un propietario de la Cuenta de AWS y ha configurado un rol para un tercero que obtiene acceso a otras Cuentas de AWS, además de la suya. Debe pedir a ese tercero un ID externo que incluye cuándo asume su rol. A continuación, busque el ID externo en la política de confianza de su rol. De este modo se garantiza que el tercero puede asumir su rol solo cuando actúa en su nombre.
+ Se encuentra en la posición de asumir roles en nombre de diferentes clientes como Example Corp en nuestra situación anterior. Debe asignar un ID externo único a cada cliente e indicarle que lo agregue a la política de confianza de su rol. A continuación, deberá asegurarse de incluir siempre el ID externo correcto en sus solicitudes para asumir roles.
Es muy probable que ya tenga un identificador único para cada uno de sus clientes y que este ID único sea suficiente para su uso como ID externo. El ID externo no es un valor especial que deba crear de forma explícita o realizar un seguimiento por separado, solo para este fin.
Siempre debe especificar el ID externo en las llamadas a la API `AssumeRole`. Además, cuando un cliente le ofrezca un ARN de rol, pruebe si puede asumir el rol tanto con como sin el ID externo correcto. Si puede asumir el rol sin el ID externo correcto, no almacene el ARN de rol del cliente en su sistema. Espere hasta que el cliente haya actualizado la política de confianza de rol para solicitar el ID externo correcto. De esta forma ayuda a sus clientes a hacer lo correcto, lo que ayuda a mantenerles a ambos protegidos frente al problema del suplente confuso.
## Escenario de ejemplo con un ID externo
Por ejemplo, digamos que decide contratar a una empresa externa denominada Example Corp para supervisar su Cuenta de AWS y ayudarlo a optimizar los costos. A fin de realizar un seguimiento de su gasto diario, Example Corp necesita acceder a los recursos de AWS. Example Corp también monitoriza muchas otras cuentas de AWS para otros clientes.
No conceda a Example Corp acceso a un usuario de IAM y sus credenciales a largo plazo en su cuenta de AWS. En su lugar, utilice un rol de IAM y sus credenciales de seguridad temporales. Un rol de IAM proporciona un mecanismo para permitir que un tercero acceda a sus recursos de AWS sin necesidad de compartir credenciales a largo plazo (por ejemplo, una clave de acceso del usuario de IAM).
Puede utilizar un rol de IAM para establecer una relación de confianza entre su Cuenta de AWS y la cuenta de Example Corp. Después de que se establezca esta relación, un miembro de la cuenta de Example Corp puede llamar a la API de AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) para obtener credenciales de seguridad temporales. A continuación, los miembros de Example Corp pueden utilizar las credenciales para obtener acceso a los recursos de AWS en su cuenta.
**nota**
Para obtener más información acerca de AssumeRole y de otras operaciones de la API de AWS que puede llamar para obtener credenciales de seguridad temporales, consulte [Comparación de credenciales AWS STS](id_credentials_sts-comparison.md).
A continuación presentamos un desglose más detallado de la situación:
1. Contrata a Example Corp para que cree un único identificador de cliente para usted. Te proporcionan este ID de cliente único y su número de Cuenta de AWS. Usted necesita esta información para crear un rol de IAM en el siguiente paso.
**nota**
Example Corp puede utilizar cualquier valor de cadena que desee para el ExternalId, siempre que sea exclusivo para cada cliente. Puede ser un número de cuenta de cliente o incluso una cadena de caracteres aleatoria, siempre que no haya dos clientes con el mismo valor. No pretende ser un "secreto". Example Corp debe proporcionar el valor ExternalId a cada cliente. Lo fundamental es que el valor lo debe generar Example Corp y ***no*** sus clientes, para garantizar que cada ID externo sea único.
1. Puede iniciar sesión en AWS y crear un rol de IAM que otorgue acceso a Example Corp a sus recursos. Como cualquier rol de IAM, el rol tiene dos políticas: una política de permisos y una política de confianza. La política de confianza del rol especifica quién puede asumir el rol. En nuestro caso, la política especifica el número de Cuenta de AWS de Example Corp como el `Principal`. Esto permite que las identidades de la cuenta asuman el rol. Además, se agrega un elemento `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` a la política de confianza. Esta `Condition` prueba la clave de contexto `ExternalId` para garantizar que coincide con el ID de cliente único de Example Corp. Por ejemplo:
```
"Principal": {"AWS": "Example Corp's Cuenta de AWS ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. La política de permisos del rol especifica qué permite realizar dicho rol. Por ejemplo, podría especificar que el rol permite administrar únicamente los recursos de Amazon EC2 y Amazon RDS, pero no los recursos de usuarios o grupos de IAM. En nuestro escenario de ejemplo, utiliza la política de permisos para ofrecer a Example Corp acceso de solo lectura a todos los recursos de la cuenta.
1. Después de crear el rol, debe proporcionar el nombre de recurso de Amazon (ARN) del rol a Example Corp.
1. Cuando Example Corp necesita acceder a los recursos de AWS, un miembro de la compañía llama a la API AWS de `sts:AssumeRole`. La llamada incluye el ARN de la función que se ha de asumir y el parámetro ExternalId que se corresponde con el ID de cliente.
Si la solicitud proviene de alguien que utiliza la Cuenta de AWS de Example Corp y si el ARN de rol y el ID externo son correctos, la solicitud se realiza correctamente. A continuación, proporciona credenciales de seguridad temporales que Example Corp puede utilizar para obtener acceso a los recursos de AWS que permite su rol.
En otras palabras, cuando una política de roles incluye un ID externo, cualquiera que desee asumir el rol debe ser principal en el rol y debe incluir el ID externo correcto.
## Puntos clave para los ID externos
+ En un entorno de varios inquilinos en el que se admiten varios clientes con cuentas de AWS diferentes, recomendamos utilizar un ID externo por cada Cuenta de AWS. Este ID debe ser una cadena aleatoria generada por el tercero.
+ Para requerir que el tercero proporcione un ID externo al asumir un rol, actualice la política de confianza del rol con el ID externo de su elección.
+ Para proporcionar un ID externo cuando asuma un rol, utilice la AWS CLI o la API de AWS para asumir ese rol. Para obtener más información, consulte la operación de la API [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) o la operación de la CLI [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html).
+ El valor `ExternalId` debe tener 2 caracteres como mínimo y 1224 como máximo. El valor debe ser alfanumérico sin espacio en blanco. También puede incluir los símbolos siguientes: más (\$1), igual (=), coma (,), punto (.), arroba (@), dos puntos (:), barra inclinada (/) y guion (-).
## Recursos adicionales
Los siguientes recursos pueden ayudarlo a obtener más información sobre cómo proporcionar acceso a las Cuentas de AWS que le pertenezcan a terceros.
+ Para obtener información sobre cómo permitir que otros realicen acciones en su Cuenta de AWS, consulte [Crear un rol mediante políticas de confianza personalizadas](id_roles_create_for-custom.md).
+ Para obtener información sobre cómo conceder permiso a fin de cambiar a un rol, consulte [Conceder a un usuario permisos para cambiar de rol](id_roles_use_permissions-to-switch.md).
+ Para obtener información sobre cómo crear y proporcionar credenciales de seguridad temporales a usuarios confiables, consulte [Permisos para credenciales de seguridad temporales](id_credentials_temp_control-access.md).
# Acceso a un servicio de AWS
Muchos servicios de AWS exigen el uso de roles para controlar a qué tiene acceso dicho servicio. Un rol que asume un servicio para realizar acciones en su nombre se denomina [rol de servicio](id_roles.md#iam-term-service-role). Si un rol tiene un fin especializado para un servicio, puede categorizarse como [rol de servicio vinculado](id_roles.md#iam-term-service-linked-role). Consulte la [AWS documentación](https://docs.aws.amazon.com/) de cada servicio para ver si utiliza roles y para aprender a asignar un rol para que lo utilice el servicio.
Para obtener más información sobre cómo crear un rol para delegar el acceso a un servicio ofrecido por AWS, consulte [Crear un rol para delegar permisos a un servicio de AWS](id_roles_create_for-service.md).
# Acceder a usuarios autenticados externamente (federación de identidades)
Es posible que los usuarios tengan ya identidades fuera de AWS, por ejemplo, en el directorio corporativo. Si estos usuarios necesitan trabajar con recursos de AWS (o con aplicaciones que necesiten acceso a dichos recursos), estos usuarios también necesitarán tener credenciales de seguridad de AWS. Puede utilizar un rol de IAM para especificar permisos para los usuarios con identidad federada de la organización o para un proveedor de identidad (IdP) externo.
**nota**
Como práctica recomendada de seguridad, le recomendamos que administre el acceso de los usuarios en [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) mediante la federación de identidades en lugar de crear usuarios de IAM. Para obtener más información acerca de situaciones específicas en las que se requiere un usuario de IAM, consulte [Cuándo crear un usuario de IAM (en lugar de un rol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose).
## Federación de usuarios de una aplicación móvil o web con Amazon Cognito
Si crea una aplicación móvil o web que tenga acceso a los recursos de AWS, esta aplicación necesita credenciales de seguridad para poder realizar solicitudes mediante programación en AWS. En la mayoría de escenarios de aplicaciones móviles, le recomendamos utilizar [Amazon Cognito](https://aws.amazon.com/cognito/). Puede utilizar este servicio con [AWS Mobile SDK para iOS](https://aws.amazon.com/sdkforios/) y [AWS Mobile SDK para Android y Fire OS](https://aws.amazon.com/sdkforandroid/) a fin de crear identidades exclusivas para usuarios y autenticarlos para proteger el acceso a sus recursos de AWS. Amazon Cognito es compatible con los mismos proveedores de identidad indicados en la sección siguiente, y también admite [identidades autenticadas por desarrollador](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) y acceso no autenticado (invitado). Amazon Cognito también ofrece operaciones de API para sincronizar los datos del usuario de modo que se preserven cuando cambia de un dispositivo a otro. Para obtener más información, consulte [Amazon Cognito para aplicaciones móviles](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito).
## Federación de usuarios con proveedores de servicio de identidad pública u OpenID Connect
Siempre que sea posible, utilice Amazon Cognito para escenarios de aplicaciones móviles y web. Amazon Cognito realiza la mayoría del trabajo en segundo plano con los servicios del proveedor de identidad pública. Funciona con los mismos servicios de terceros y también admite inicios de sesión anónimos. Sin embargo, en los escenarios más avanzados, puede trabajar directamente con un servicio de terceros como Login with Amazon, Facebook, Google o cualquier proveedor (IdP) compatible con OpenID Connect (OIDC). Para obtener más información sobre el uso de la federación OIDC con uno de estos servicios, consulte [Federación OIDC](id_roles_providers_oidc.md).
## Federación de usuarios con SAML 2.0
Si su organización ya utiliza un paquete de software de proveedor de identidad que admite SAML 2.0 (Security Assertion Markup Language 2.0), puede crear una relación de confianza entre su organización como proveedor de identidad (IdP) y AWS como proveedor del servicio. Entonces podrá utilizar SAML para proporcionar a los usuarios un inicio de sesión único (SSO) federado para el acceso a la Consola de administración de AWS o acceso federado a las llamadas a operaciones de API de AWS. Por ejemplo, si su compañía utiliza Microsoft Active Directory y Active Directory Federation Services, puede realizar la federación con SAML 2.0. Para obtener más información sobre cómo federar usuarios con SAML 2.0, consulte [Federación SAML 2.0](id_roles_providers_saml.md).
## Federación de usuarios mediante la creación de una aplicación personalizada de agente de identidades
Si su almacén de identidades no es compatible con SAML 2.0, puede crear una aplicación personalizada de agente de identidades para llevar a cabo una función similar. La aplicación de agente autentica a los usuarios, solicita credenciales temporales para los usuarios de AWS y les proporciona acceso a los recursos de AWS.
Por ejemplo, Example Corp. tiene muchos empleados que necesitan ejecutar aplicaciones internas que obtengan acceso a los recursos de AWS de la compañía. Los empleados ya tienen identidades en el sistema de autenticación e identidad de la compañía y Example Corp. no quiere crear otro usuario de IAM para cada empleado de la compañía.
Bob es un desarrollador de Example Corp. Para permitir que las aplicaciones internas de la compañía obtengan acceso a los recursos de AWS, Bob desarrolla una aplicación personalizada de agente de identidades. La aplicación verifica que los empleados hayan iniciado sesión en el sistema existente de autenticación e identidad de Example Corp., que podría utilizar LDAP, Active Directory u otro sistema. La aplicación de agente de identidades obtiene credenciales de seguridad temporales para los empleados. Este escenario es similar al anterior (una aplicación móvil que utiliza un sistema personalizado de autenticación), salvo que todas las aplicaciones que necesitan acceso a los recursos de AWS se ejecutan en la red corporativa y la compañía tiene un sistema existente de autenticación.
Para obtener credenciales de seguridad temporales, la aplicación de agente de identidades llama a `AssumeRole` o `GetFederationToken` para obtener credenciales de seguridad temporales, en función del modo en que Bob quiere administrar las políticas para los usuarios y el momento en el que las credenciales temporales caduquen. (Para obtener información sobre las diferencias entre estas operaciones de API, consulte [Credenciales de seguridad temporales en IAM](id_credentials_temp.md) y [Permisos para credenciales de seguridad temporales](id_credentials_temp_control-access.md)). La llamada devuelve credenciales de seguridad temporales que incluyen un token de sesión, una clave de acceso secreta y un ID de clave de acceso de AWS. La aplicación de agente de identidades pone a disposición de la aplicación interna de la compañía estas credenciales de seguridad temporales. La aplicación puede utilizar las credenciales temporales para realizar llamadas a AWS directamente. La aplicación almacena en caché las credenciales hasta que caducan y solicita un nuevo conjunto de credenciales temporales. La siguiente figura ilustra este escenario.
![\[Ejemplo de flujo de trabajo mediante la utilización de una aplicación de agentes de identidades personalizada\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
Este escenario tiene los siguientes atributos:
+ La aplicación de agente de identidades tiene permisos para obtener acceso a la API de Security Token Service (STS) de IAM para crear credenciales de seguridad temporales.
+ La aplicación de agente de identidades puede verificar que los empleados estén autenticados en el sistema existente de autenticación.
+ Los usuarios pueden obtener una dirección URL temporal que les proporcione acceso a Management Console de AWS (lo que se denomina inicio de sesión único).
Para obtener información sobre la creación de credenciales de seguridad, consulte [Comparación de credenciales AWS STS](id_credentials_sts-comparison.md). Para obtener más información sobre cómo las entidades principales federadas de SAML obtienen acceso a la Consola de administración de AWS, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md).