Configuración del SSO de navegador web SAML en Liberty

Puede configurar un servidor Liberty para que funcione como un proveedor de servicio de inicio de sesión único (SS) de navegador web SAML.

Acerca de esta tarea

Puede configurar un servidor Liberty como un proveedor de servicio de SSO web SAML habilitando la característica samlWeb-2.0 en Liberty y, además, otra información de configuración.

Procedimiento

  1. Añada la característica de Liberty samlWeb-2.0 al archivo server.xml añadiendo la declaración de elemento siguiente dentro del elemento featureManager.
    <feature>samlWeb-2.0</feature>
  2. Liberty proporciona un elemento samlWebSso20 predeterminado.
    <samlWebSso20 id="defaultSP">
    
    </samlWebSso20>
    En esta configuración predeterminada, se presuponen los valores predeterminados siguientes:
    • AssertionConsumerService URL:
      https://<nombrehost>:<puertossl>
      /ibm/saml20/defaultSP/acs
    • URL de metadatos de proveedor de servicio (PS):
      https://<nombrehost>:<puertossl>
      /ibm/saml20/defaultSP/samlmetadata

      Puede utilizar un navegador para descargar los metadatos para este proveedor de servicio (PS) utilizando este URL, y proporcionar el URL al proveedor de identidad SAML para establecer una federación entre este PS y el proveedor de identidad (IdP).

    • El archivo de metadatos de IdP se debe copiar en el directorio resources/security en el servidor, y se llama idpMetadata.xml.
    • EL asunto del emisor para la aserción SAML se utiliza como dominio de seguridad, y el NameID se utiliza como el principal para crear un sujeto autenticado de la aserción SAML.
    • El SAML AuthnRequest se firma con una clave privada del almacén de claves predeterminados del servidor, si no se especifica el atributo KeyStoreRef. Si no se ha configurado keyAlias, samlsp es el alias de clave predeterminado. Si no se ha configurado el keyAlias y el almacén de claves solo contiene una clave privada, se utiliza la clave privada en la firma.
    Nota: Si crea una nueva instancia de proveedor de servicio y el defaultSP ya no es necesario, debe inhabilitar de forma explícita la instancia defaultSP, añadiendo lo siguiente al archivo server.xml.
    <samlWebSso20 id="defaultSP" enabled="false">  
    </samlWebSso20>
    Nota: Es necesario que especifique una serie segura de URL que no sea nula como el ID para samlWebSso20. Si falta el id, se omite el elemento de configuración y no se maneja como el defaultSP.
    Nota: Cuando SAML está configurado y habilitado, todas las solicitudes autenticadas utilizarán la autenticación de SAML. Para configurar los tipos de solicitudes que deberían y no deberían utilizar la autenticación de SAML, debe configurar un filtro de autenticación, tal como se describe en el paso 15.
  3. Opcional: puede añadir <samlWebSso20 id="defaultSP"> al archivo server.xml y personalizar el proveedor de servicio defaultSP. Por ejemplo:
    • idpMetadata: añada este parámetro para cambiar la ubicación de metadatos de IdP y el nombre de archivo de la ubicación predeterminada y el nombre de archivo (${server.config.dir}/resources/security/idpMetadata.xml).
    • userIdentifier: añada este parámetro para seleccionar un nombre de atributo de SAML cuyo valor se utiliza como el nombre principal.
    • groupIdentifier: añada este parámetro para seleccionar un nombre de atributo SAML cuyos valores se incluyen como miembros de grupo en el sujeto.
    • realmName: utilice este parámetro para especificar de forma explícita el nombre del reino para identificar un principal de SAML en este proveedor de servicio. El nombre de reino predeterminado es el nombre del emisor de SAML.
  4. Opcional: puede crear uno o varios elementos samlWebSso20 com un ID diferente. Por ejemplo, si crea un nuevo elemento con un ID como mySP, podrá crear de forma eficaz una nueva instancia de PS de SAML que tiene un nuevo URL AssertionConsumerService:
    https://<nombrehost>:<puertossl>/ibm/saml20/mySP/acs
    Nota: El ID que elija para samlWebSso20 se incluye en el URL del PS, incluyendo el URL AssertionConsumerService y el URL de metadatos. El ID samlWebSso20 no debe estar vacío y no debe contener caracteres de URL no seguros.
  5. Opcional: puede configurar un motor de confianza. El PS de SAML de Liberty soporta dos tipos de motores de confianza:
    • Motor de confianza de metadatos: valida la firma con respecto a la información que se proporciona en los metadatos de IdP configurados.
    • Motor de confianza de PKIX: valida la fiabilidad del certificado en la firma a través de la validación de PKIX. Los certificados que pasan esta validación se suponen que son de confianza.

    Los metadatos son el motor de confianza predeterminado. Si desea utilizar el motor de confianza PKIX, tendrá que añadir el elemento PKIXTrustEngine y definir el trustAnchor adecuado.

  6. Opcional: puede configurar cómo crear un sujeto autenticado de SAML. De forma predeterminada, el PS de Liberty crea un sujeto a partir de la aserción SAML directamente sin el requisito de un registro de usuarios locales, que es equivalente a la configuración de mapToUserRegistry=No. Las otras opciones de configuración son mapToUserRegistry=User o mapToUserRegistry=Group.
    • mapToUserRegistry=No: el nombre del emisor de SAML es el reino y el NameID se utiliza para crear un nombre 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 de SAML en el registro de usuarios internos y cree el sujeto de usuario basándose en el registro de usuarios internos.
    • 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 similar a mapToUserRegistry=No, excepto para los miembros de grupo que se verifican en el registro de usuarios internos.
  7. Opcional: puede implementar el SPI de SAML Liberty, com.ibm.wsspi.security.saml2.UserCredentialResolver como una característica de usuario para correlacionar de forma dinámica una aserción SAML con un sujeto Liberty.
  8. Opcional: puede definir reglas para indicar al IdP cómo autenticar un usuario configurando uno o más de los atributos siguientes cuando se utiliza un flujo de SSO web iniciado por el PS: forceAuthn, isPassive, allowCreate, authnContextClassRef y authnContextComparisonType.
  9. Opcional: puede definir un formato NameID necesario en AuthnRequest utilizando el atributo nameIDFormat. Puede especificar cualquier formato NameID que está definido en la especificación de SAML, o utilizar la palabra clave customize para especificar el formato NameId personalizado.
  10. Opcional: puede configurar varios socios de federación de PS e IdP creando varios elementos samlWebSso20, y cada samlWebSso20 hace referencia a un elemento authFilter exclusivo. Todos los authFilters deben excluirse entre sí. Con varios samlWebSso20 configurados, cada uno puede realizar un inicio de sesión único con su proveedor de identidad federada y tiene su propia política de autenticación y reglas de consumo.
  11. Opcional: añada soporte para el SSO no solicitado iniciado por el IdP. El PS SAML Liberty soporte el SSO no solicitado iniciado por el IdP con y sin el requisito de las instalaciones locales de metados de IdP. Si no tiene metadatos de IdP, o si tiene previsto utilizar el SSO no solicitado para federar con varios proveedores de identidiad con un PS de Liberty, debe añadir las configuraciones siguietes:
    • Configure <PKIXTrustEngine> e importe todos los certificados de firmante de IdP al almacén de confianza predeterminado del servidor Liberty, o el trustAnchor del PKIXTrustEngine.
    • Configure trustedIssuers para listar el nombre de emisor del IdP como aparece en la aserción SAML. El nombre de emisor se utiliza como el EntityID en los metadatos.
    • Si tiene previsto soportar solo el SSO no solicitado, puede configurar el SSO no solicitado iniciado por el PS, tal como se documenta en el paso siguiente. Este escenario es útil si el contexto de seguridad de usuario en el PS que está asociado a SAML se invalida, el PS puede volver a redireccionar el usuario al IdP para volver a iniciar automáticamente el SSO no solicitado.
  12. Opcional: añada soporte para el SSO no solicitado iniciado por el PS. El PS de SAML Liberty utiliza metadatos de IdP configurados para realizar una AuthnRequest de SAML solicitada. Es posible para el PS De Liberty redireccionar solicitudes sin autenticar a una aplicación de inicio de sesión preconfigurado sin utilizar AuthnRequest. Este escenario es útil si una aplicación empresarial realizar un proceso previo a la autenticación antes de que un usuario puede autenticarse en el IdP de SAML, o el IdP de SAML debe estar oculto del PS de Liberty. Para configurar este escenario, añada el atributo loginPageURL, y establezca su valor en un URL que puede indicar a un usuario que se autentique en el IdP de SAML.
  13. Opcional: configure requisitos de firma con las consideraciones siguientes:
    • Aserción SAML. El IdP de SAML debe firmar de forma digital todas las aserciones SAML. En las raras ocasiones en las que desea aceptar una aserción no firmada, puede configurar wantAssertionsSigned=false de forma explícita.
    • El algoritmo de firma predeterminado es SHA256. Si debe cambiar el algoritmo, utilice el atributo signatureMethodAlgorithm para modificarlo.
    • Si no desea firmar el SAML AuthnRequest, puede establecer authnRequestsSigned=false.
  14. Opcional: puede configurar una cookie y una sesión de autenticación de PS. Una vez que se ha verificado y procesado de aserción SAML, el PS de SAML Liberty mantiene una sesión autenticada entre el navegador 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áticamehnte y puede personalizar el nombre de la cookie utilizando el atributo spCookieName para especificar el nombre deseado.

    Si desea que el PS de Liberty cree una cookie LTPA a partir de la aserción SAML y que 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 autentica directamente en un registro de usuarios internos que impide que un usuario tenga dos cuentas.
  15. Opcional: configure el filtro de autenticación.

    Cuando la característica samlWeb-2.0 está habilitada, cualquier solicitud no autenticada se autentica a través de un PS SAML. Si define un elemento samlWebSso20 personalizado, todas las solicitudes de autenticación son manejadas por esta instancia de PS samlWebSso20; de lo contrario, toda la autenticación es manejada por la instancia predeterminada defaultSP. Puede utilizar authnFilter para definir qué instancia de PS maneja la solicitud de autenticación.

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

  16. Opcional: configure el PS de SAML en un clúster.

    Si los servidores de aplicaciones son miembros del clúster y utiliza un direccionador o un servidor proxy inverso para direccionar las solicitudes, tendrá que realizar las tareas siguientes:

    • El direccionador y el servidor proxy se deben configurar para dar soporte a la afinidad de sesiones.
    • Añada el atributo de configuración spHostAndPort a cada servidor de aplicaciones y establezca su valor en el nombre de host y el puerto del direccionador o servidor proxy. Por ejemplo, spHostAndPort="https://myRouter.com:443".
    • Genere un certificado X509 para firmar el SAML AuthnRequest y utilice este certificado en todos los servidores de aplicaciones. Por ejemplo, puede crear un almacén de claves para contener solo este certificado y añada KeyStoreRef para hacer referencia a este almacén de claves en todos los servidores de aplicaciones.
    • Si createSession="true" no está establecido en un entorno de clúster, se encuentra el error siguiente durante una ejecución con mucha carga:
      E CWWKS5029E: El estado de
      retransmisor [sp_initial_KGe22fCWKG1lD9VkOMuDz0Ji8pBxFPnU] en la
      respuesta del proveedor de identidad (IdP) no se ha reconocido.
    Aquí aparece una configuración de clúster de ejemplo:
    <keyStore id="samlKeyStore" password="<password>"
                  location="${server.config.dir}/resources/security/<samlKey.jks>" />
    
            <samlWebSso20  id="defaultSP"
                   spHostAndPort="https://<IHS host>:<port>"
                   keyStoreRef="samlKeyStore"
                   createSession="true"
                   allowCustomCacheKey="false"
                   disableLtpaCookie="false"
                   mapToUserRegistry="User">
            </samlWebSso20>

Resultados

Ahora ha establecido la configuración que es necesaria para configurar un servidor Liberty como un proveedor de servicio SAML con capacidad de una sola firma en proveedores de identidad SAML.

Icono que indica el tipo de tema Tema de tarea



Icono de indicación de fecha y hora Última actualización: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_config_saml_web_sso
Nombre de archivo:twlp_config_saml_web_sso.html