Configuración de la propagación de entrada web SAML en Liberty

Puede configurar un servidor Liberty para que acepte una señal SAML en una cabecera HTTP como una señal de autenticación. Esta característica se utiliza normalmente para un cliente proxy o RESTful que utiliza SAML en nombre de un usuario autenticado.

1. Añada la característica samlWeb-2.0 de Liberty al archivo server.xml añadiendo la declaración de elemento dentro del elemento featureManager.

   
   <feature>samlWeb-2.0</feature>

2. Habilite la propagación de entrada SAML. El servidor Liberty proporciona un elemento samlWebSso20 predeterminado.

   
   
   <samlWebSso20 id="defaultSP">
   
   </samlWebSso20>

   Puede utilizar este elemento samlWebSso20 predeterminado o crear un elemento samlWebSso20 nuevo para habilitar la propagación de entrada SAML añadiendo inboundPropagation=required.

   
   <samlWebSso20 id="defaultSP" inboundPropagation="required" >
   </samlWebSso20>

   Nota: Cuando SAML está configurado y habilitado, todas las solicitudes no autenticadas utilizan la autenticación SAML. Para configurar los tipos de solicitudes que pueden y no pueden utilizar la autenticación SAML, debe configurar un filtro de autenticación, tal como se describe en este tema.
3. Debe configurar el motor de confianza PKIX para validar la fiabilidad del certificado en la firma a través de la validación PKIX. Los certificados que pasan esta validación se suponen que son de confianza.
   1. Configure <PKIXTrustEngine> e importe todos los certificados de firmante SAML de confianza al almacén de confianza predeterminado del servidor Liberty o al trustAnchor de PKIXTrustEngine.
   2. Opcional: configure trustedIssuers para que liste el nombre del emisor de la señal SAML como aparece en la aserción SAML, si la fiabilidad del certificado no es suficiente.
   El ejemplo siguiente es una configuración de ejemplo:

   
   <samlWebSso20  id="defaultSP"          
     inboundPropagation="required"
     headerName="saml_token"
     signatureMethodAlgorithm="SHA1">
     <pkixTrustEngine trustAnchor="serverStore" />
   </samlWebSso20>  

4. Opcional: puede añadir headerName para definir un nombre de cabecera de solicitud http que contiene una señal SAML. Si este atributo de configuración no está definido, el servidor Liberty busca el nombre de cabecera saml, Saml y SAML para la señal SAML. La cabecera de la señal SAML en la solicitud HTTP puede adoptar uno de los formatos siguientes:

   
   Authorization=[<headerName>=<AQUÍ_SAML>]                  
   Authorization=[<headerName>="<AQUÍ_SAML>"] 
   Authorization=[<headerName> <AQUÍ_SAML>]
   <headerName>=[<AQUÍ_SAML>]

   La señal SAML debe estar codificada con Base-64 o UTF-8 y se puede comprimir con el formato GZIP.

   Nota: El nombre de cabecera de la señal SAML debe ser una serie de URL segura y no debe contener espacios en blanco inicial o finales.
5. Opcional: puede configurar cómo crear un sujeto autenticado de SAML. De forma predeterminada, el proveedor de servicio Liberty crea un sujeto a partir de una aserción SAML directamente, sin el requisito de un registro de usuarios locales, que es equivalente a la opción mapToUserRegistry=No de configuración. Las otras opciones de configuración son mapToUserRegistry=User o mapToUserRegistry=Group.
   • mapToUserRegistry=No: El nombre del emisor de SAML es reino, y se utiliza el NameID para crear un nombre principal y un nombre de seguridad único en el sujeto, y no se incluye ningún miembro de grupo. Puede configurar los atributos: userIdentifier, realmIdentifier, groupIdentifier y userUniqueIdentifier para crear un sujeto autenticado con un nombre de usuario personalizado, nombre de reino, miembros de grupo e identificador de seguridad exclusivo.
   • mapToUserRegistry=User: Elija esta opción si desea validar un usuario SAML con respecto al registro de usuarios locales y crear el sujeto del usuario, basándose en el registro de usuarios locales.
   • mapToUserRegistry=Group: elija esta opción si desea validar un grupo de SAML en el registro de usuarios locales y crea un sujeto para que contenga estos grupos validados. Esta opción es is similar a mapToUserRegistry=No, excepto que las pertenencias de grupo se verifican con respecto al registro de usuarios locales.
6. Opcional: Puede implementar la SPI SAML Liberty, com.ibm.wsspi.security.saml2.UserCredentialResolver, como una característica de usuario para correlacionar dinámicamente una aserción SAML con un sujeto de Liberty.
7. Opcional: puede configurar varios elementos samlWebSso20 y cada elemento samlWebSso20 hace referencia a un elemento authFilter exclusivo. Todos los elementos authFilter deben excluirse entre sí. Con varios elementos samlWebSso20 configurados, cada uno tiene sus propias política de autenticación y reglas de consumo.
8. Opcional: configure requisitos de firma con las consideraciones siguientes:

   El algoritmo de firma predeterminado es SHA256. Si debe cambiar el algoritmo, utilice el atributo signatureMethodAlgorithm para modificarlo.

9. Opcional: puede configurar una cookie y una sesión de autenticación de PS. Una vez que se ha verificado y procesado la aserción SAML, el PS de SAML Liberty mantiene una sesión autenticada entre el cliente y el PS sin utilizar una cookie LTPA. El tiempo de espera de sesión autenticada está establecido en SessionNotOnOrAfter en <saml:AuthnStatement> si está presente, o sessionNotOnOrAfter tal como se ha configurado en el archivo server.xml, con el valor predeterminado de 120 minutos. El nombre de cookie de sesión se genera automáticamente y puede personalizar el nombre de la cookie utilizando el atributo spCookieName para especificar el nombre deseado.

   Si desea que el SP Liberty cree una cookie LTPA a partir de la aserción SAML y utilice la cookie LTPA para las solicitudes de autenticación posteriores, puede añadir la configuración disableLtpaCookie=false. Si desea compartir la cookie LTPA con otros servidores, debe añadir el atributo de configuración allowCustomCacheKey="false".

   Nota: Si configura disableLtpaCookie="false" y allowCustomCacheKey="false", asegúrese de que un nombre de usuario SAML no se está autenticando directamente en un registro de usuarios locales que impide a un usuario tener dos cuentas.
10. Configure el filtro de autenticación. Puede utilizar authnFilter para definir qué elemento samlWebSso20 va a manejar la solicitud de autenticación de propagación de entrada.

    Si desea más información sobre cómo configurar el filtro de autenticación, consulte filtros de autenticación.