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.
Acerca de esta tarea
Puede configurar un servidor Liberty para aceptar una señal SAML en una cabecera HTTP como una señal de autenticación habilitando la característica samlWeb-2.0
en Libertyy estableciendo inboundPropagation=required
además de otra información de configuración. La configuración para la propagación de entrada es similar a Configuración del inicio de sesión único del navegador web SAML en Liberty.
Procedimiento
- Añada la característica
samlWeb-2.0
Liberty al archivo server.xml añadiendo la siguiente declaración de elemento dentro del elementofeatureManager
.<feature>samlWeb-2.0</feature>
- Habilite la propagación de entrada SAML. El servidor Liberty proporciona un elemento
samlWebSso20
predeterminado.<samlWebSso20 id="defaultSP"> </samlWebSso20>
Puede utilizar este elementosamlWebSso20
predeterminado o crear un elementosamlWebSso20
nuevo para habilitar la propagación de entrada SAML añadiendoinboundPropagation=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. - 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.
- Configure
<PKIXTrustEngine>
e importe todos los certificados de firmante SAML de confianza al almacén de confianza predeterminado del servidor de Liberty o altrustAnchor
dePKIXTrustEngine
. - 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>
- Configure
- 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 cabecerasaml
,Saml
ySAML
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
oUTF-8
y se puede comprimir con el formatoGZIP
.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. - 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 sonmapToUserRegistry=User
omapToUserRegistry=Group
.mapToUserRegistry=No
: el nombre del emisor SAML es realm, yNameID
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
yuserUniqueIdentifier
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 amapToUserRegistry=No
, excepto que las pertenencias de grupo se verifican con respecto al registro de usuarios locales.
- 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 . - Opcional: puede configurar varios elementos
samlWebSso20
y cada elementosamlWebSso20
hace referencia a un elementoauthFilter
exclusivo. Todos los elementosauthFilter
deben excluirse entre sí. Con varios elementossamlWebSso20
configurados, cada uno tiene su propia política de autenticación y reglas de consumo. - Opcional: configure requisitos de firma con las
consideraciones siguientes:
El algoritmo de firma predeterminado es
SHA256
. Si debe cambiar el algoritmo, utilice el atributosignatureMethodAlgorithm
para modificarlo. - 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 ensessionNotOnOrAfter
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 atributospCookieName
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ónallowCustomCacheKey="false"
.Nota: Si configuradisableLtpaCookie="false"
yallowCustomCacheKey="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. - Configure el filtro de autenticación. Puede utilizar
authnFilter
para definir qué elementosamlWebSso20
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.