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

Puede configurar un servidor Liberty para aceptar 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 Liberty al archivo server.xml añadiendo la siguiente 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 de Liberty o al trustAnchor de PKIXTrustEngine.
   2. Opcional: Configure el trustedIssuers para listar el nombre de emisor de la señal SAML tal 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 contenga una señal SAML. Si este atributo de configuración no está definido, el servidor Liberty busca el nombre de cabecera saml, Samly 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>=<SAML_HERE>]                  
   Authorization=[<headerName>="<SAML_HERE>"] 
   Authorization=[<headerName> <SAML_HERE>]
   <headerName>=[<SAML_HERE>]

   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 señal SAML debe ser una serie segura de URL y no debe contener espacios en blanco iniciales ni finales.
5. Opcional: puede configurar cómo crear un sujeto autenticado de SAML. De forma predeterminada, el proveedor de servicios Liberty crea un sujeto a partir de una aserción SAML directamente sin el requisito de un registro de usuarios local, que es equivalente a la configuración mapToUserRegistry=No. Las otras opciones de configuración son mapToUserRegistry=User o mapToUserRegistry=Group.
   • mapToUserRegistry=No: el nombre del emisor SAML es realm, y NameID se utiliza para crear un nombre de principal y un nombre de seguridad exclusivo 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 Liberty SAML SPI, com.ibm.wsspi.security.saml2.UserCredentialResolver como una característica de usuario para correlacionar dinámicamente una aserción SAML con un sujeto 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 su propia 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. Después de verificar y procesar la aserción SAML, el SP SAML de Liberty mantiene una sesión autenticada entre el cliente y el SP sin utilizar una cookie LTPA. El tiempo de espera de sesión autenticada se establece en SessionNotOnOrAfter en <saml:AuthnStatement> si se presenta, o en sessionNotOnOrAfter tal como se ha configurado en el archivo server.xml , siendo el valor predeterminado de 120 minutos. El nombre de cookie de sesión se genera automáticamente y puede personalizar el nombre de 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 utiliza 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 autentica directamente en un registro de usuarios local que impida que un usuario tenga dos cuentas.
10. Configure el filtro de autenticación. Puede utilizar authnFilter para definir qué elemento samlWebSso20 debe manejar la solicitud de autenticación de propagación de entrada.

    Para obtener más información sobre cómo configurar el filtro de autenticación, consulte Filtros de autenticación.