Federación SAML 2.0

AWS admite la federación de identidades con SAML 2.0 (Lenguaje de marcado para confirmaciones de seguridad 2.0), un estándar abierto que utilizan muchos proveedores de identidad (IdP). Esta característica permite el inicio de sesión único (SSO) federado para que los usuarios puedan iniciar sesión en la AWS Management Console o llamar a operaciones de la API de AWS sin necesidad de crear un usuario de IAM para cada persona de la organización. Al utilizar SAML, puede simplificar el proceso de configuración de la federación con AWS, ya que puede utilizar el servicio del proveedor de identidades en lugar de escribir el código proxy de identidad personalizado.

La federación de IAM admite estos casos de uso:

• Acceso federado para permitir que un usuario o aplicación de su organización llame a las operaciones de API de AWS. Este caso de uso se analiza en la siguiente sección. Utiliza una afirmación SAML (como parte de la respuesta de autenticación) que se genera en la organización para obtener credenciales de seguridad temporales. Esta situación es similar a otras situaciones de federación que admite IAM, como las descritas en Solicitud de credenciales de seguridad temporales y Federación OIDC. Sin embargo, los proveedores de identidad SAML 2.0 de su organización gestionan gran parte de los detalles en el tiempo de ejecución para realizar la comprobación de la autenticación y la autorización.

• Inicio de sesión único (SSO) basado en web en la AWS Management Console desde su organización. Los usuarios pueden iniciar sesión en un portal de la organización alojado por un proveedor de identidades compatible con SAML 2.0, seleccionar una opción para ir a AWS y ser redireccionados hacia la consola sin tener que proporcionar información de inicio de sesión adicional. Puede utilizar un IdP SAML de terceros para establecer el acceso SSO a la consola, o también puede crear un IdP personalizado para conceder acceso a la consola a los usuarios externos. Para obtener más información acerca de la creación de un proveedor de identidad personalizado, consulte Permitir el acceso del agente de identidades personalizadas a la consola de AWS.

Temas

• Uso de la federación basada en SAML para el acceso a la API de AWS
• Información general sobre la configuración de la federación basada en SAML 2.0
• Información general acerca del rol que permite el acceso federado SAML a los recursos de AWS
• Identificación única de los usuarios en la federación basada en SAML
• Crear un proveedor de identidades de SAML en IAM
• Configuración su SAML 2.0 IdP con una relación de confianza para usuario autenticado y agregando reclamos
• Integración de proveedores de soluciones SAML externos con AWS
• Configure aserciones SAML para la respuesta de autenticación
• Concesión de acceso a la AWS Management Console a los usuarios federados SAML 2.0

Uso de la federación basada en SAML para el acceso a la API de AWS

Imagine que desea proporcionar un método para que los empleados copien datos de sus equipos a una carpeta de copia de seguridad. Puede crear una aplicación que los usuarios pueden ejecutar en sus equipos. En la etapa final, la aplicación lee y escribe objetos en un bucket de Amazon S3. Los usuarios no tienen acceso directo a AWS. En su lugar, se utiliza el siguiente proceso:

1. Un usuario de su organización utiliza una aplicación cliente para solicitar autenticación del proveedor de identidad de su organización.

2. El proveedor de identidad autentica al usuario en función del almacén de identidades de la organización.

3. El proveedor de identidad construye una aserción de SAML con información sobre el usuario y envía dicha aserción a la aplicación cliente.

4. La aplicación cliente llama a la API AWS STSAssumeRoleWithSAML de , transfiriendo el ARN del proveedor SAML, el ARN del rol a asumir y la aserción de SAML del proveedor de identidad.

5. La respuesta de la API a la aplicación cliente incluye credenciales de seguridad temporales.

6. La aplicación cliente usa las credenciales de seguridad temporales para llamar a las operaciones de API de Amazon S3.

Información general sobre la configuración de la federación basada en SAML 2.0

Antes de poder utilizar la federación basada en SAML 2.0 tal y como se describe en la situación anterior y en el diagrama, debe configurar el proveedor de identidad de su organización y su Cuenta de AWS para que confíen el uno en el otro. El proceso general para configurar esta confianza se describe en los pasos siguientes. Dentro de su organización, debe contar con un proveedor de identidades compatible con SAML 2.0, como Microsoft Active Directory Federation Service (AD FS, parte de Windows Server), Shibboleth u otro proveedor SAML 2.0 compatible.

nota

Para mejorar la resiliencia de la federación, le recomendamos que configure su IdP y su federación de AWS para que admitan varios puntos de conexión de inicio de sesión de SAML. Para obtener más información, consulte el artículo del blog sobre seguridad de AWS, How to use regional SAML endpoints for failover.

Configure que la IdP de su organización y AWS confíen el uno en el otro

1. Registre AWS como proveedor de servicios (SP) con el IdP de su organización. Utilice el documento de metadatos SAML de https://region-code.signin.aws.amazon.com/static/saml-metadata.xml

   Para obtener una lista de los posibles valores de region-code, consulte la columna Region (Región) en Puntos de conexión de inicio de sesión de AWS.

   Opcionalmente, puede usar el documento de metadatos SAML de https://signin.aws.amazon.com/static/saml-metadata.xml .

2. Con el IdP de la organización puede generar un archivo XML de metadatos equivalente que describe su IdP como proveedor de identidad de IAM en AWS. Debe incluir el nombre de emisor, una fecha de creación, una fecha de vencimiento y claves que AWS puede utilizar para validar las respuestas de autenticación (aserciones) de la organización.

3. En la consola de IAM, debe crear un proveedor de identidad SAML. Como parte de este proceso, puede cargar el documento de metadatos SAML producidos por el IdP en la organización en Paso 2. Para obtener más información, consulte Crear un proveedor de identidades de SAML en IAM.

4. En IAM, debe crear uno o varios roles de IAM. En la política de confianza del rol, se establece el proveedor SAML como principal, que establece una relación de confianza entre la organización y AWS. La política de permisos del rol establece qué usuarios de la organización pueden realizar qué cosas en AWS. Para obtener más información, consulte Creación de un rol para un proveedor de identidad de terceros (federación).

   nota

   Los proveedores de identidad de SAML que se utilizan en una política de confianza de roles deben estar en la misma cuenta en la que se encuentra el rol.

5. En el proveedor de identidad de la organización, defina aserciones que asignen usuarios o grupos de la organización a los roles de IAM. Tenga en cuenta que los distintos usuarios y grupos de la organización pueden asignarse a diferentes roles de IAM. Los pasos exactos para llevar a cabo la asignación dependerán del proveedor de identidad que esté utilizando. En la situación anterior de una carpeta de Amazon S3 para los usuarios, es posible que todos los usuarios estén asignados al mismo rol que proporciona los permisos de Amazon S3. Para obtener más información, consulte Configure aserciones SAML para la respuesta de autenticación.

   Si el proveedor de identidades activa el inicio de sesión único en la consola de AWS, puede configurar la duración máxima de las sesiones de la consola. Para obtener más información, consulte Concesión de acceso a la AWS Management Console a los usuarios federados SAML 2.0 .

6. En la aplicación que esté creando, llame a la API AWS Security Token Service AssumeRoleWithSAML, que transfiere el ARN del proveedor SAML que creó en Paso 3, el ARN del rol a asumir que creó en Paso 4 y la aserción de SAML sobre el usuario actual que obtiene del proveedor de identidades. AWS se asegurará de que la solicitud para asumir el rol procede del proveedor de identidades al que se hace referencia en el proveedor SAML.

   Para obtener más información, consulte AssumeRoleWithSAML en la Referencia de la API de AWS Security Token Service.

7. Si la solicitud se realiza correctamente, la API devuelve un conjunto de credenciales de seguridad temporales, que su aplicación puede utilizar para realizar solicitudes firmadas a AWS. Su aplicación tiene información sobre el usuario actual y puede acceder a carpetas específicas del usuario en Amazon S3, tal y como se describe en la situación anterior.

Información general acerca del rol que permite el acceso federado SAML a los recursos de AWS

El rol o roles que crea en IAM definen lo que los usuarios federados de la organización pueden realizar en AWS. Al crear la política de confianza para el rol, debe especificar el proveedor SAML que creó anteriormente como Principal. Además puede ampliar la política de confianza con una Condition para permitir únicamente a los usuarios que cumplen determinados atributos SAML acceder al rol. Por ejemplo, puede especificar que solo los usuarios cuya afiliación SAML es staff (tal como afirma https://openidp.feide.no) estén autorizados para acceder al rol, tal y como se muestra en la siguiente política de muestra:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

nota

Los proveedores de identidad de SAML que se utilizan en una política de confianza de roles deben estar en la misma cuenta en la que se encuentra el rol.

Para obtener más información sobre las claves de SAML que puede revisar en una política, consulte Claves disponibles para la federación AWS STS basada en SAML.

Puede incluir puntos de conexión regionales para el atributo saml:aud en https://region-code.signin.aws.amazon.com/static/saml-metadata.xml. Para obtener una lista de los posibles valores de region-code, consulte la columna Region (Región) en Puntos de conexión de inicio de sesión de AWS.

Para la política de permisos del rol, debe especificar los permisos de la misma forma que haría para cualquier rol. Por ejemplo, si los usuarios de la organización pueden administrar las instancias Amazon Elastic Compute Cloud (EC2), debe permitir de forma explícita las acciones de Amazon EC2 en la política de permisos, como los de la política administrada AmazonEC2FullAccess.

Identificación única de los usuarios en la federación basada en SAML

Al crear políticas de acceso en IAM, a menudo es útil poder especificar los permisos basados en la identidad de los usuarios. Por ejemplo, en el caso de los usuarios que se han federado mediante SAML, es posible que una aplicación quiera conservar información en Amazon S3 utilizando una estructura de este tipo:

myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3

Puede crear el bucket (myBucket) y la carpeta (app1) a través de la consola de Amazon S3 o la AWS CLI, pues son valores estáticos. Sin embargo, las carpetas específicas de usuarios (user1, user2, user3, etc.) deben crearse en el tiempo de ejecución utilizando código, ya que el valor que identifica al usuario es desconocido hasta la primera vez que el usuario inicia sesión a través del proceso de federación.

Para escribir políticas que hacen referencia a detalles específicos del usuario como parte de un nombre de recurso, la identidad del usuario tiene que estar disponible en claves SAML que puedan utilizarse en las condiciones de políticas. Las siguientes claves están disponibles para la federación basada en SAML 2.0 para utilizarlas en las políticas de IAM. Puede utilizar los valores devueltos por las siguientes claves para crear identificadores de usuario únicos para recursos como carpetas de Amazon S3.

• saml:namequalifier. Un valor hash basado en la concatenación del Issuer valor de respuesta (saml:iss) y una cadena con el ID de cuenta AWS y el nombre fácil de recordar (la última parte del ARN) del proveedor SAML en IAM. La concatenación del ID de cuenta y del nombre fácil de recordar del proveedor SAML está disponible para las políticas de IAM como clave saml:doc. El ID de cuenta y el nombre de proveedor deben separarse con una "/" como en "123456789012/provider_name". Para obtener más información, consulte la clave saml:doc en Claves disponibles para la federación AWS STS basada en SAML.

  La combinación de NameQualifier y Subject se puede utilizar para identificar un usuario federado de forma unívoca. El pseudocódigo siguiente muestra cómo se calcula este valor. En este pseudocódigo, + indica una concatenación, SHA1 representa una función que genera un resumen del mensaje utilizando SHA-1 y Base64 representa una función que genera una versión con codificación Base64 de la salida del hash.

  Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

  Para obtener más información acerca de las claves de la política que están disponibles para la federación basada en SAML, consulte Claves disponibles para la federación AWS STS basada en SAML.

• saml:sub (cadena). Se trata del asunto de la demanda, que incluye un valor que identifica de forma unívoca a un usuario individual dentro de una organización (por ejemplo, _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).

• saml:sub_type (cadena). Esta clave puede ser persistent, transient o la URI completa Format de los elementos Subject y NameID utilizados en la aserción SAML. Un valor de persistent indica que el valor de saml:sub es el mismo para un usuario en todas las sesiones. Si el valor es transient, el usuario tendrá un valor saml:sub diferente para cada sesión. Para obtener información sobre el atributo NameID del elemento Format, consulte Configure aserciones SAML para la respuesta de autenticación.

El siguiente ejemplo muestra una política de permisos que utiliza las claves anteriores para conceder permisos a una carpeta específica de usuario en Amazon S3. La política presupone que los objetos de Amazon S3 se identifican utilizando un prefijo que incluye tanto saml:namequalifier y saml:sub. Observe que el elemento Condition incluye una prueba para asegurarse de que saml:sub_type está fijado en persistent. Si se establece como transient, el valor saml:sub para el usuario puede ser diferente en cada sesión, por lo que la combinación de los valores no debe utilizarse para identificar las carpetas específicas del usuario.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

Para obtener más información sobre la asignación de aserciones del proveedor de identidad a claves de políticas, consulte Configure aserciones SAML para la respuesta de autenticación.