Acerca de la federación basada en SAML 2.0 - AWS Identity and Access Management

Acerca de la federación basada en 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 Consola de administración de AWS o invocar las 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:

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 S3. Los usuarios no tienen acceso directo a AWS. En su lugar, se utiliza el siguiente proceso:


          Obtención de credenciales de seguridad temporales basadas en una aserción de SAML
  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 AssumeRoleWithSAML de AWS STS, que transfiere el ARN del proveedor SAML, el ARN del rol a asumir y la aserción de SAML del proveedor de identidades.

  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 usar 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 la organización y la 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.

Para configurar que el proveedor de identidad de la organización y la cuenta de AWS confíen el uno en el otro

  1. Puede comenzar el registro de AWS con el proveedor de identidad. En el proveedor de identidad de la organización, registre AWS como proveedor de servicios (SP) utilizando el documento de metadatos SAML que obtiene de la dirección URL siguiente:

    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 una entidad de proveedor de identidad SAML. Como parte de este proceso, puede cargar el documento de metadatos SAML producido por el proveedor de identidad en la organización en Paso 2. Para obtener más información, consulte Creación de proveedores de identidad SAML de 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).

  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 Configuración de 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 Consola de administración de AWS a los usuarios federados de SAML 2.0.

    nota

    La implementación de la federación SAML 2.0 en AWS no admite aserciones SAML cifradas entre el proveedor de identidad de IAM y AWS. Sin embargo, el tráfico entre los sistemas del cliente y AWS se transmite a través de un canal (TLS) cifrado.

  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-WITHOUT-HYPHENS: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"]} } }] }

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.

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, 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 Configuración de 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 Configuración de aserciones SAML para la respuesta de autenticación.