Escenarios de uso de SAML

La función SAML se describe mediante cuatro escenarios de uso básicos. Los tres primeros escenarios muestran un inicio de sesión único de servicios web, configurado utilizando un conjunto de políticas. El cuarto escenario describe un inicio de sesión único SAML personalizado, que se puede crear mediante la API de SAML y la API de cliente de confianza. Los escenarios muestran mediante bloques de creación y API de SAML cómo autenticarse en un servicio de señales de seguridad (STS), solicitar señales SAML e implementar las señales SAML para obtener acceso a servicios empresariales.

Visión general

WebSphere Application Server con SAML proporciona bloques de compilación y API que permiten crear soluciones de inicio de sesión único y soluciones empresariales de federación de identidades mediante señales SAML. Los conjuntos de políticas SAML son los bloques de compilación para configurar aplicaciones de servicios web con el fin de solicitar señales SAML, propagar señales SAML en mensajes SOAP y validar y autenticar señales SAML, todo ello sin una sola línea de programación.

Con las API de SAML y las API de cliente de WS-Trust, puede crear mediante programación señales SAML, analizar y validar señales SAML y autenticar señales SAML recibidas de protocolos que no sean mensajes SOAP de servicios Web. Específicamente, utilice las API SAML para procesar atributos de señal SAML personalizados, crear interfaces de aplicación personalizadas y realizar autorizaciones basadas en reclamaciones. Utilice la API de cliente WS-Trust para solicitar señales SAML u otros tipos de señales, desde un STS y para validar e intercambiar señales con un STS.

El producto WebSphere Application Server no incluye un STS para emitir SAML ni ningún otro tipo de señal de seguridad. Sin embargo, WebSphere Application Server con SAML no interactúa con Tivoli Federated Identity Manager y otras implementaciones de STS de terceros.

Escenario 1: Inicio de sesión único (SSO) de servicios Web

En este escenario de inicio de sesión único (SSO), un usuario se autentica con un STS y solicita señales SAML con el método de confirmación bearer. El usuario utiliza, a continuación, señales SAML para acceder a un proveedor de servicios empresariales. El proveedor de servicios empresariales valida las señales SAML y confirma la identidad y los atributos del usuario según la relación de confianza entre el proveedor y el STS emisor. Las señales SAML recibidas se consideran válidas si los certificados de firma de señales son de confianza para el proveedor de servicios empresariales y si la hora de caducidad de las señales es inferior a la hora local del proveedor de servicios empresariales más un desfase horario configurable.

El proveedor de servicios empresariales puede acceder a servicios en sentido descendente en nombre del usuario que utilice señales SAML según la configuración de políticas del servicio. Con la configuración de políticas, el proveedor de servicios puede propagar las señales SAML originales o generar SAML autoemitido según los atributos de usuario originales. Para obtener una descripción detallada sobre cómo configurar conjuntos de políticas y enlaces para este escenario, consulte la información sobre cómo configurar enlaces de cliente y proveedor para la señal bearer SAML.

El inicio de sesión único con una señal bearer SAML tiene ventajas sobre otra tecnología de SSO porque SAML es una señal de seguridad estándar y la admiten varios productos de proveedor. Además, la implementación de por parte de WebSphere Application Server de la función SAML interactúa con Tivoli Federated Identity Manager, DataPower y otros productos de proveedor.

En este diagrama se muestra la interacción entre el STS y el proveedor de servicios empresariales en el escenario de inicio de sesión único de servicios web.
Figura 1. Escenario de uso de inicio de sesión único de servicios Web
Escenario de inicio de sesión único (SSO) con señal bearer SAML

Puede añadir un enlace de llamante a los enlaces de ejemplo de proveedor SAML para seleccionar la señal SAML recibida que representa la identidad de llamante. El entorno de ejecución de seguridad de servicios Web utiliza el NameID de SAML para representar la identidad de cliente y buscar el nombre de seguridad de usuario y los miembros de grupo en el registro de usuarios configurado cuando se utiliza la configuración de inicio de sesión JAAS system.wss.caller predeterminada.

Una vez que este escenario se ejecuta correctamente, el entorno de ejecución de WS-Security guarda las señales SAML y puede reutilizarlas para acceder al proveedor de servicios empresariales, si las señales aún son válidas. La señal es válida si el tiempo de caducidad de la señal es inferior al periodo de memoria caché, que se puede configurar. Una vez que el proveedor de servicios empresariales ha validado y autenticado las señales SAML recibidas, los sujetos JAAS, junto con las señales SAML correspondientes, se guardan en la memoria caché de autenticación. La señal SAML sigue siendo válida en el servidor de aplicaciones de alojamiento independientemente del tiempo de caducidad de la señal. Esto significa que el entorno de ejecución de WS-Security no comprueba el tiempo de caducidad de señales SAML dentro del mismo proceso, porque las señales SAML siguen siendo válidas en el proceso del servidor de aplicaciones siempre que la señal esté en la memoria caché de autenticación.

Los tiempos de caducidad de las señales SAML se comprueban cuando el proveedor de servicios empresariales utiliza las señales SAML para invocar servicios en sentido descendente. Las solicitudes de salida fallarán si el tiempo de caducidad de señales SAML no es inferior al tiempo actual añadido al periodo de memoria caché. Esta limitación también se aplica cuando la configuración de políticas exige el uso de las señales SAML originales. No obstante, la limitación no se aplica si la configuración de políticas utiliza, en cambio, señales SAML autoemitidas, por ejemplo, si el proveedor de servicios empresariales ha creado y firmado una reproducción de las señales SAML originales.

Escenario 2: inicio de sesión único (SSO) de servicios Web con validación mediante holder-of-key

El escenario de uso de inicio de sesión único con validación mediante holder-of-key es similar al escenario de uso de SSO anterior. El escenario de SSO con holder-of-key utiliza señales SAML con el método de confirmación holder-of-key (HoK) en lugar del método de confirmación bearer. Las señales HoK SAML contienen una clave que el cliente utiliza para probar la propiedad de la clave y la propiedad de la señal. Esta clave incorporada puede ser una clave compartida (denominada también clave simétrica) o un certificado X.509 con una clave pública (denominada también como clave asimétrica). En el caso de una clave compartida, la clave se cifra mediante la clave pública del proveedor de servicios empresariales de destino, de manera que sólo el servicio empresarial pretendido pueda consumir los mensajes SOAP.

Cuando un cliente solicita señales SAML con la clave compartida HoK de un STS, el STS cifra la clave en las señales SAML y envía una copia de la misma clave en la respuesta WS-Trust al cliente solicitante. Esto es necesario porque, si no, el cliente no puede leer las claves cifradas en las señales SAML. Para probar la propiedad de las señales SAML, el cliente utiliza al clave compartida para firmar y cifrar los mensajes de solicitud SOAP. Los servicios empresariales son obligatorios para validar la propiedad de las señales HoK extrayendo la clave compartida cifrada y utilizándola para verificar la firma digital.

El diagrama siguiente muestra cómo un servicio web puede solicitar una señal SAML en el escenario.
Figura 2. Servicios Web 1 que solicitan una señal SAML de un servicio externo
Escenario de validación de inicio de sesión único (SSO) con holder-of-key

 1  El usuario inicia sesión con un navegador web mediante SPNEGO y se autentica. Se crea un sujeto JAAS.

 2  La credencial de la señal SPNEGO se utiliza para solicitar una señal SAML con WS-Trust. La señal se firma con la clave privada de servidor de confianza.

 3  La firma de la señal SAML se valida según la relación de confianza. La credencial de seguridad se crea con los atributos de la señal SAML. La clave criptográfica de la señal SAML se utiliza para descifrar el mensaje SOAP.

Como se muestra en el diagrama, un cliente de navegador utiliza las credenciales de Kerberos (representadas por la señal SPNEGO) para acceder a una aplicación web. Suponiendo que la credencial Kerberos se pueda delegar, la aplicación web puede solicitar una señal SAML del STS en nombre del cliente, utilizando la credencial Kerberos de cliente delegado. Por ejemplo, la aplicación web obtiene una señal Kerberos de solicitud de aprobación de cliente (APREQ) del centro de distribución de claves (KDC) en nombre del cliente. La aplicación web utiliza, a continuación, la señal APREQ de cliente para autenticarse en el STS y solicita una señal SAML de cliente del STS en nombre del cliente.

En este ejemplo, la señal exige el método de confirmación holder-of-key con una clave simétrica. La aplicación Web utiliza la señal SAML para acceder a los servicios empresariales en sentido descendente, también en nombre del cliente, de manera que la señal SAML autentica el cliente con los servicios en sentido descendente y también protege los mensajes de solicitud mediante la firma y el cifrado digital. Para obtener más información sobre cómo configurar enlaces para la señal HoK, consulte la información sobre la configuración de enlaces de cliente y proveedor para la señal de clave simétrica holder-of-key SAML.

Cuando el escenario se ejecuta correctamente, los servicios empresariales de destino pueden utilizar la señal SAML para acceder a otros servicios en sentido descendente con el mismo procedimiento que se describe en el escenario, si los servicios empresariales en sentido descendente pueden extraer la clave incorporada. Como alternativa, los servicios empresariales se pueden configurar para utilizar señales SAML autoemitidas para acceder a servicios en sentido descendente con el fin de evitar distribuir la clave privada.

Escenario 3: gestión de identidades federadas de servicios Web

En el escenario de uso de gestión de identidades federadas, un cliente de navegador accede a una aplicación Web del portal de la empresa. En este escenario, los datos de autenticación de usuario básicos, como el nombre de usuario y la contraseña, se utilizan para solicitar señales SAML de un STS y, a continuación, las señales SAML se utilizan para obtener acceso a servicios empresariales entre dominios de seguridad. El proveedor de servicios empresariales receptor valida las señales SAML según la relación de confianza entre el proveedor y el STS emisor y el proveedor también confirma la identidad y los atributos del usuario. Esto significa que el usuario no tiene que definirse anteriormente en el directorio del usuario de los servicios empresariales de destino. Una ventaja de este escenario es que proporciona una manera más gestionable de federar servicios empresariales de muchos socios comerciales conjuntamente y elimina, a la vez, la necesidad de consolidar los usuarios en un servicio de directorio de usuarios.

Figura 3. Un usuario inicia sesión en un portal de empresa y utiliza la gestión de identidades federadas para obtener acceso a los servicios empresariales
Escenario de gestión de identidades federadas

 1  El usuario inicia sesión con un nombre de usuario y una contraseña y se autentica en el portal de la empresa. Se crea un sujeto JAAS.

 2  El nombre del usuario y la contraseña se utilizan para autenticarse en el STS y para solicitar una señal SAML que represente al usuario.

 3  La firma de la señal SAML se valida según la relación de confianza. Las credenciales de seguridad se crean con los atributos de la señal SAML. La clave criptográfica de la señal SAML se utiliza para descifrar el mensaje SOAP.

La configuración de inicio de sesión del sistema predeterminada, wss.caller, correlaciona las identidades de usuario que representan las señales SAML con las identidades de usuario del directorio de usuarios configurado. Debe añadirse un módulo de inicio de sesión personalizado a la configuración de inicio de sesión wss.caller para confirmar las identidades de usuario de señales SAML de otros dominios de seguridad en el servidor de aplicaciones. Este módulo de inicio de sesión personalizado extrae la identidad de usuario de señal SAML y otros atributos y crea propiedades de aserción que utiliza el servidor de aplicaciones. Dos de estas propiedades, el nombre de usuario y la identidad de usuario, son obligatorias para el servidor de aplicaciones. Dado que las dos propiedades se proporcionan en la aserción de identidad, el servidor de aplicaciones no tiene que validar el nombre de usuario en el directorio de usuarios local.

Además, se puede proporcionar la información acerca de los miembros de grupos de usuarios al servidor de aplicaciones. Esta información se utiliza para construir el objeto WSCredential que representa las credenciales de seguridad del servidor de aplicaciones para el usuario. Las propiedades de usuario se pasan al WSWSSLoginModule de servidor de aplicaciones utilizando el estado compartido LoginContext de JAAS. Para obtener información detallada sobre estas propiedades, consulte la información acerca de la configuración de la correlación de identidades de entrada.

Escenario 4: Soluciones de inicio de sesión único (SSO) personalizado

En el escenario de uso de inicio de sesión único (SSO) personalizado se utilizan las API de biblioteca de señales SAML, las API de cliente de WS-Trust y otras API y SPI de servidor de aplicaciones para crear soluciones de SSO personalizado que se adapten a un entorno informático de empresa concreto. El diagrama de este escenario muestra un ejemplo en el que los usuarios se autentican y se emiten para ellos señales SAML desde un proveedor de identidades que tiene una relación de confianza con un servidor de empresa. En este escenario, una empresa otorga a los usuarios acceso a las aplicaciones web protegidas en función de la relación de confianza, sin solicitar a los usuarios ninguna otra autenticación.

Los clientes de aplicaciones Web, como los navegadores web, pasan señales SAML al servidor de aplicaciones con el protocolo HTTPS, en lugar de utilizar el protocolo de servicios web. Para interceptar y pasar estas solicitudes, la empresa crea un interceptor de asociación de confianza (TAI) SAML que implementa la API de interceptor de asociación de confianza del servidor de aplicaciones. Un TAI SAML utiliza la API de la biblioteca de señales SAML para validar y autenticar señales SAML. Como alternativa, el TAI SAML puede utilizar la API de cliente WS-Trust para validar y autenticar señales SAML en un STS externo. Para obtener más información acerca de la interfaz de TAI, consulte la información acerca del desarrollo de un interceptor personalizado para asociaciones de confianza. Con WebSphere Application Server no se entrega ningún TAI SAML personalizado.

Figura 4. Un usuario inicia sesión en un servidor de empresa con un navegador web con el protocolo HTTPS y se autentica con un TAI SAML
Escenario de inicio de sesión único (SSO) personalizado

 1  El usuario inicia sesión en un proveedor de identidades con un nombre de usuario y una contraseña. Los proveedores de identidades emiten una señal SAML ante el usuario.

 2  El TAI SAML utiliza la API SAMLTokenFactory para validar la señal SAML y para autenticar la señal SAML para crear credenciales de usuario. El TAI SAML también puede utilizar la API de cliente WS-Trust para validar la señal SAML con un STS externo.

Para obtener más información sobre las API SAML, consulte al información acerca de la API de cliente WS-Trust y las API de la biblioteca de señales SAML.

Una solución más compleja: varios dominios de seguridad

En las secciones anteriores de este documento se describen cuatro casos de uso básico. Sin embargo, es posible que desee realizar la aserción de las señales de SAML en varios límites de dominio de seguridad. Para obtener más información sobre esta solución, consulte la documentación acerca de las aserciones SAML en los dominios de seguridad de WebSphere Application Server.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_samlusagescenarios
File name: cwbs_samlusagescenarios.html