Liberty: Autenticación

La autenticación en la seguridad de Liberty es confirmar la identidad de un usuario.

Para acceder a un recurso web protegido, el usuario debe proporcionar datos de credenciales como, por ejemplo, el ID de usuario y la contraseña. El proceso de autenticación requiere recopilar esta información de credenciales de usuario (basada en cómo se ha configurado la aplicación web para recopilar estos datos) y validarla en un registro configurado. Cuando se verifica la información de credenciales, se crea un sujeto JAAS para dicho usuario. El sujeto contiene más información sobre el usuario como, por ejemplo, los grupos a los que pertenece el usuario y las señales que se han creado para el usuario. La información de este sujeto se utiliza durante el proceso de autorización para determinar si el usuario puede acceder al recurso.

El siguiente diagrama ilustra un proceso de flujo de autenticación típico para un recurso web.

Figura 1. Visión general del proceso de autenticación El servicio de autenticación utiliza módulos de inicio de sesión JAAS para manejar la autenticación.

El proceso de autenticación requiere la recopilación de datos de credenciales de autenticación del usuario, la comprobación de la memoria caché para ver si el sujeto existe para dicho usuario y, de no ser así, la llamada al servicio JAAS para realizar la autenticación con la que crear un sujeto. El servicio JAAS llama a un conjunto de módulos de inicio de sesión para manejar la autenticación. Uno o varios de los módulos de inicio de sesión crean el sujeto en función de los datos de credenciales. El módulo de inicio de sesión llama al registro que se ha configurado para validar la información de credenciales. Si la validación se ha realizado correctamente, el proceso de autenticación recopila y crea información relevantes para dicho usuario, incluyendo los grupos a los que pertenece el usuario y la señal de inicio de sesión único (SSO) que se utiliza para la prestación de SSO y los almacena en el sujeto como credenciales relevantes. También puede personalizar la información que se guarda en el sujeto conectando los módulos de inicio de sesión personalizado durante este proceso.

Cuando la autenticación se realiza satisfactoria, la señal de SSO que se crea durante el proceso se vuelve a enviar al navegador en una cookie. El nombre predeterminado de la cookie configurable es ltpaToken2. En posteriores llamadas, la información de la señal información se utiliza para autenticar al usuario. Si la autenticación falla, el servicio de autenticación intenta utilizar otros datos de autenticación, tales como el ID de usuario y contraseña, si todavía existen en la solicitud.
Nota: Para admitir ID de usuario y contraseñas que contienen caracteres ASCII de EE.UU., es necesario el método de inicio de sesión de formulario para las aplicaciones web. Para obtener más información, consulte autoRequestEncoding y autoResponseEncoding.

Registros de usuario

Cuando se validan los datos de autenticación de un usuario, los módulos de inicio de sesión los módulos llaman al registro de usuarios que se ha configurado para validar la información de usuario. Liberty soporta un registro de usuario basado en configuración simple y un registro basado en LDAP más sólido. Para obtener más información, consulte Configuración de un registro de usuarios en Liberty.

Utilizando el registro LDAP, también puede federar varios repositorios y ejecutar las operaciones LDAP en dos o más registros. El usuario de Liberty puede configurar la característica del registro LDAP ya sea directamente en el archivo server.xml o puede configurar en la sección Federación de registro LDAP en la herramienta de desarrollador. Después de la configuración de los repositorios federados, puede obtener un resultado consolidado de los repositorios federados en cualquier operación que desee realizar. Por ejemplo, si desea realizar una operación de búsqueda para todos los nombres de usuario que empiezan con test, puede realizar una búsqueda en el conjunto de registros LDAP y obtener el resultado de búsqueda consolidados, que después se puede devolver al programa de llamada.

Memoria caché de autenticación

Dado que la creación de un sujeto es relativamente costosa, Liberty proporciona una memoria caché de autenticación para almacenar un sujeto después de que la autenticación de un usuario se realice correctamente. El tiempo de caducidad predeterminado para la memoria caché es 10 minutos. Si el usuario no vuelve a iniciar la sesión en 10 minutos, se elimina el sujeto y el proceso de autenticación se repite para crear un sujeto para dicho usuario. Los cambios en la configuración que afectan a la creación del sujeto, como añadir un módulo de inicio de sesión o cambiar las claves LTPA, provoca que la memoria caché de autenticación se borre. Si el sujeto se almacena en la memoria caché y la información en el registro cambia, la memoria caché se actualiza con la información del registro. Puede configurar el periodo de tiempo espera de memoria caché y el tamaño de la memoria caché, y también puede inhabilitar o habilitar la memoria caché. Para obtener más información, consulte Configuración de la memoria caché de autenticación en Liberty.

Configuración JAAS

La configuración JAAS define un conjunto de módulos de inicio de sesión para crear el sujeto. Liberty da soporte a las siguientes configuraciones JAAS:
system.WEB_INBOUND
Se utiliza cuando se accede a recursos web como, por ejemplo, servlets y JSP.
WSLogin
Se utiliza en las aplicaciones cuando se utiliza el inicio de sesión programado. También lo utilizan aplicaciones que se ejecutan en un contenedor de cliente de aplicaciones, pero, a diferencia de la configuración de ClientContainerJAAS, no reconoce el manejador CallbackHandler especificado en el descriptor de despliegue del módulo de aplicación cliente.
system.DEFAULT
Se utiliza para el inicio de sesión cuando no se especifica ninguna configuración JAAS.
system.DESERIALIZE_CONTEXT
Se utiliza cuando se está deserializando un contexto de seguridad. Esta configuración JAAS maneja la autenticación para volver a crear los sujetos que estaban activos en la hebra en el momento de serializar el contexto de seguridad. Puede especificar esta configuración JAAS y añadir sus propios módulos de inicio de sesión JAAS personalizados editando la entrada de configuración de JAAS en el archivo server.xml para asegurarse de que los sujetos propagados contienen la información personalizada.
ClientContainer
Lo utilizan las aplicaciones que se ejecutan en un contenedor de cliente de aplicaciones. Esta configuración de inicio de sesión de JAAS reconoce el manejador CallbackHandler especificado en el descriptor de despliegue del módulo de aplicación cliente, si se ha especificado uno.
Las configuraciones system.WEB_INBOUND y system.DEFAULT tienen estos módulos de inicio de sesión predeterminados en este orden: hashtable, userNameAndPassword, certificate y token. La configuración WSLogin tiene el módulo de inicio de sesión de proxy como módulo de inicio de sesión predeterminado, y el proxy delega todas las operaciones al módulo de inicio de sesión real en system.DEFAULT.

No se necesita ninguna configuración explícita a menos que desee realizar una personalización con módulos de inicio de sesión personalizados. En función de los requisitos, puede personalizar las configuraciones de inicio de sesión específicas. Por ejemplo, si desea que todos los inicios de sesión de recursos web se personalicen, debe añadir sólo módulos de inicio de sesión personalizados a la configuración system.WEB_INBOUND. Consulte Configuración de un módulo de inicio de sesión personalizado JAAS para Liberty.

Módulos de inicio de sesión de JAAS

La configuración JAAS utiliza un conjunto de módulos de inicio de sesión para crear el sujeto. Liberty proporciona un conjunto de módulos de inicio de sesión en cada una de las configuraciones de inicio de sesión. En función de los datos de autenticación, un módulo de inicio de sesión específico crea el sujeto. Los datos de autenticación se pasan a los módulos de inicio de sesión utilizando el manejador de devolución de llamada según se define en la especificación de JAAS. Por ejemplo, si se utiliza el manejador de retorno de llamada de ID de usuario y contraseña para la autenticación, el módulo de inicio de sesión de userNameAndPassword maneja la autenticación. Si se presenta una credencial SingleSignonToken como datos de autenticación, sólo el módulo de inicio de sesión token maneja la autenticación.

Los siguientes módulos de inicio de sesión predeterminados están soportados en Liberty:
userNameAndPassword
Maneja la autenticación cuando se utilizan el nombre de usuario y la contraseña como datos de autenticación.
certificate
Maneja la autenticación cuando se utiliza un certificado X509 como los datos de autenticación de SSL mutuo.
token
Maneja la autenticación cuando se presenta una señal SSO como datos de autenticación. Durante el proceso de autenticación, se crea una señal SSO y se devuelve al cliente HTTP (navegador) en una cookie. En las solicitudes posteriores, esta cookie se vuelve a enviar mediante el navegador y el servidor extrae la señal de la cookie para autenticar al usuario cuando se habilita el inicio de sesión único.
hashtable
Se utiliza cuando los datos de autenticación se envían a través de una tabla hash predefinida. Para obtener más información sobre el inicio de sesión de la tabla hash, consulte la sección Módulo de inicio de sesión de tabla hash. Este módulo de inicio de sesión también lo utiliza en el tiempo de ejecución de la seguridad de ejecución cuando se realiza la autenticación utilizando sólo la identidad; por ejemplo, en el caso de runAs.
proxy
El módulo de inicio de sesión predeterminado para WSLogin. Consulte Módulo de inicio de sesión de proxy.

Los módulos de inicio de sesión se invocan en el orden en que están configurados. El orden predeterminado es hashtable, userNameAndPassword, certificate, token. Si debe personalizar el proceso de inicio de sesión utilizando módulos de inicio de sesión personalizados, puede proporcionarlos y configurarlos en el orden que necesite. Normalmente, coloque un módulo de inicio de sesión personalizado en primer lugar en la lista de módulos de inicio de sesión, para que se invoque el primero. Cuando se utiliza un módulo de inicio de sesión personalizado, debe especificar toda la información del módulo de inicio de sesión en la configuración junto con el módulo de inicio de sesión personalizado en el orden necesario.

Cuando un módulo de inicio de sesión determina que puede manejar la autenticación, primero se asegura de que los datos de autenticación que se han pasado sean válidos. Por ejemplo, para la autenticación de nombre de usuario y contraseña, se llama al registro de usuarios configurado para verificar la información de autenticación. Para la autenticación de señales, la señal debe estar cifrada y debe ser válida para que la verificación sea correcta.

Cuando la autenticación de datos se ha validado, los módulos de inicio de sesión crean credenciales con datos adicionales para el usuario incluidos los grupos y la señal SSO. Un módulo de inicio de sesión personalizado puede añadir más datos al sujeto creando sus propias credenciales. Para que la autorización Liberty funciones, el sujeto debe contener las credenciales WSCredential, WSPrincipal y SingleSignonToken. La credencial WSCredential contiene la información de grupos, con información adicional que es necesaria para el entorno de ejecución de seguridad.

Manejador de retorno de llamada

Liberty soporta distintos manejadores de devolución de llamada para proporcionar datos a los módulos de inicio de sesión durante el proceso de autenticación JAAS. Un módulo de inicio de sesión personalizado utiliza la información del manejador de retorno de llamada para autenticarse a sí mismo. Por ejemplo, si el manejador de devolución de llamada debe acceder a alguna información en un objeto HttpServletRequest, puede hacerlo utilizando dicho manejador de devolución de llamada específico.

Los siguientes manejadores de retorno de llamada y fábricas para el inicio de sesión JAAS programado están soportados en Liberty:
  • com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
  • com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
La documentación de la API Java para cada API Liberty está disponible en un archivo .zip separado en uno de los subdirectorios javadoc del directorio ${wlp.install.dir}/dev.

Consulte Desarrollo de módulos de inicio de sesión personalizados JAAS para una configuración de inicio de sesión en el sistema.

Credenciales y señales

Como se ha mencionado en la sección loginModule , las credenciales se crean como parte del proceso de creación del sujeto. Liberty crea las credenciales WSCredential, SingleSignonToken y WSPrincipal. La credencial SingleSignonToken contiene la señal que se devuelve al navegador en una cookie para que funcione SSO. Esta señal contiene la información de usuario y una hora de caducidad. Está firmada y cifrada mediante las claves LTPA (Lightweight Third Party Authentication) que se generan durante el primer arranque del servidor. El tiempo de caducidad predeterminado es de 2 horas y es un tiempo absoluto, que no está basado en las actividades del usuario. Después de 2 horas, la señal caduca y el usuario debe volver a iniciar sesión para acceder al recurso.

LTPA

LTPA se ha diseñado para entornos distribuidos de varios servidores de aplicaciones. Liberty, LTPA da soporte a SSO y a la seguridad en un entorno distribuido mediante criptografía. Este soporte permite a LTPA cifrar, firmar digitalmente y transmitir de forma segura los datos relacionados con autenticación y posteriormente, descifrar y verificar la firma.

Los servidores de aplicaciones se pueden comunicar con seguridad mediante el protocolo LTPA. El protocolo también proporciona la característica SSO, en la que un usuario sólo necesita autenticarse cuando se está conectando a un sistema de nombres de dominio (DNS). A continuación, el usuario puede acceder a recursos en otros servidores Liberty en el mismo dominio sin que se le solicite. Los nombres de reino de cada sistema del dominio DNS son sensibles a las mayúsculas y minúsculas y deben ser idénticos.

El protocolo LTPA utiliza claves criptográficas para cifrar y descifrar los datos de usuario que se pasan entre los servidores. Estas claves se deben compartir entre servidores diferentes para que los recursos en un servidor puedan acceder a los recursos en otros servidores, suponiendo que todos los servidores implicados utilizan el mismo registro de usuarios. LTPA requiere que el registro de usuarios configurado sea un repositorio compartido centralmente, para que los usuarios y los grupos sean los mismos, independientemente del servidor.

Cuando se utiliza LTPA, se crea una señal que contiene la información de usuario y una hora de caducidad, firmada por las claves. La señal de LTPA es sensible a la hora. Todos los servidores participantes deben tener la hora y la fecha sincronizadas. De no ser así, las señales LTPA caducan de forma prematura y provocan errores de autenticación o validación. La hora universal coordinada (UTC) se utiliza de manera predeterminada, y todos los demás servidores deben tener la misma hora UTC. Consulte la documentación del sistema operativo para obtener información sobre cómo garantizar la misma hora UTC entre servidores.

La señal LTPA se pasa a otros servidores a través de las cookies para los recursos web cuando está habilitado SSO.

Si los servidores receptores utilizan las mismas claves que el servidor original, la señal se puede descifrar para obtener la información de usuario, que se valida a continuación para asegurarse de que la señal no ha caducado y que la información de usuario de la señal es válida en su registro. Si la validación es satisfactoria, se puede acceder a los recursos en los servidores receptores después de la comprobación de autorización.

Cada servidor debe tener credenciales válidas. Cuando caducan las credenciales, es necesario que el servidor se comunique con el registro de usuarios para autenticarse. Ampliar el tiempo que la señal LTPA permanece en la memoria caché aumenta ligeramente el riesgo de seguridad y se ha de tener en cuenta cuando se definen las políticas de seguridad.

Si es necesario compartir las claves entre distintos servidores de Liberty, copie las claves de un servidor a otro. Para fines de seguridad, las claves se cifran con una clave generada aleatoriamente y se utiliza una contraseña definida por el usuario para proteger las claves. Esta misma contraseña se necesitará cuando se importen las claves a otro servidor. La contraseña sólo se utiliza para proteger las claves y no para generarlas.

Cuando la seguridad está habilitada, LTPA se ha configurado de forma predeterminada durante la hora de inicio del servidor Liberty. Para obtener más información sobre el soporte LTPA, consulte la sección Configuración de LTPA en Liberty.

OpenID

OpenID es un estándar de autenticación abierto que permite a los usuarios autenticarse en varias entidades sin la necesidad de gestionar varias cuentas o conjuntos de credenciales. Liberty soporta el estándar OpenID Authentication 2.0 funcionando como una parte Relying Party (parte de confianza). En este estándar, una Relying Party requiere confirmación de autenticación de un proveedor OpenID. En lugar de proporcionar credenciales a la Relying Party, los usuarios se redireccionan al proveedor OpenID para enviar sus credenciales. El proveedor OpenID confirma el resultado de autenticación con la Relying Party y devuelve un identificador exclusivo que es propiedad del usuario, posiblemente además de un subconjunto de información personal que está aprobada por el usuario como el nombre de usuario o la dirección de correo electrónico. La Relying Party puede utilizar esta información para completar la autenticación sin necesidad de manejar las credenciales del usuario. Además, los usuarios pueden utilizar una sola cuenta con un proveedor OpenID para autenticarse ellos mismos con cualquier entidad que actúe como una Relying Party, sin la necesidad de gestionar o crear cuentas exclusivas para cada entidad.

Si desea más información sobre OpenID, consulte OpenID. Para configurar OpenID en un servidor Liberty, consulte Configuración de una Relying Party de OpenID en Liberty.

OpenID Connect

OpenID Connect es un protocolo de identidad simple y un estándar abierto que se basa en el protocolo OAuth 2.0. OpenID Connect permite a las aplicaciones cliente confiar en la autenticación realizada por un proveedor OpenID Connect para verificar la identidad de un usuario.

Las aplicaciones cliente también pueden obtener información de perfil básica sobre un usuario final de una forma interoperable y al estilo de REST de proveedores de OpenID Connect. El soporte de OpenID Connect se basa en el estándar OpenID Connect Standard v1.0.

Si desea más información sobre OpenID Connect, consulte OpenID Connect. Para configurar un cliente de OpenID Connect, o una Relying Party, en un servidor Liberty, consulte Configuración de un cliente de OpenID Connect en Liberty. Para configurar un proveedor de OpenID Connect en un servidor Liberty, consulte Configuración de un proveedor de OpenID Connect en Liberty.

SPNEGO

SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) permite a los usuarios iniciar la sesión en el controlador de dominio de Microsoft una sola vez y acceder a aplicaciones protegidas de servidores Liberty sin nuevas solicitudes.

Cuando la autenticación web SPNEGO está habilitada y el cliente de navegador accede a un recurso protegido del servidor de Liberty, SPNEGO es responsable de autenticar el acceso al recurso protegido que se identifica en la solicitud HTTP. El cliente de navegador crea una señal SPNEGO y la envía al servidor de Liberty como parte de la solicitud HTTP. WebSphere Application Server valida y recupera la identidad de usuario de la señal SPNEGO. La identidad se utiliza para establecer un contexto seguro entre el usuario y el servidor de aplicaciones.

Si desea más información sobre SPNEGO, consulte Inicio de sesión único para las solicitudes HTTP mediante la autenticación Web SPNEGO. Si desea más información sobre cómo configurar SPNEGO en el servidor Liberty, consulte Configuración de la autenticación SPNEGO en Liberty.

Delegación restringida de Kerberos para SPNEGO

La característica de la delegación restringida de Kerberos proporciona dos API que se utilizan para crear señales SPNEGO de salida para los servicios de programa de fondo que soporta la autenticación SPNEGO, como servidores de .NET y otros servidores de Liberty.

La extensión de Kerberos v5 denominada S4U (Servicios para usuarios) consta de dos partes:
S4U2self

Permite que un servidor de Liberty obtenga un ticket de servicio para sí mismo en nombre de un usuario. Se puede utilizar con cualquier forma de autenticación soportada por Liberty. S4U2self es la extensión de transición de protocolo de Kerberos.

S4U2proxy

Permite que un servidor de Liberty obtenga tickets de servicio a servicios de confianza en nombre de un usuario. Estos tickets de servicio se obtienen utilizando un ticket de servicio del usuario al servicio de Liberty. Los servicios los restringe el administrador del Centro de distribución de claves de Kerberos (KDC). S4U2proxy es la extensión de delegación restringida de Kerberos.

Inicio de sesión único (SSO)

SSO permite al usuario iniciar la sesión en un lugar (por ejemplo un servidor) y acceder a aplicaciones en otros servidores sin que se le solicite de nuevo. Para que SSO funcione, las claves LTPA deben intercambiarse entre los diferentes servidores de Liberty, los registros de usuario deben ser los mismos y la señal no debe haber caducado. Para intercambiar las claves LTPA, puede copiar el archivo ltpa.keys de un servidor a otro y reiniciar el servidor para que utilice las nuevas claves LTPA. Los registros utilizados por todos los servidores que participan en el dominio SSO deben ser los mismos.

Cuando un usuario se autentica en un servidor Liberty, la señal SSO que se crea para el usuario durante el proceso de autenticación se coloca en la cookie que se envía al cliente HTTP, por ejemplo un navegador. Si hay otra solicitud de ese cliente para acceder a otro conjunto de aplicaciones de un servidor diferente, pero en el mismo DNS que se ha configurado como parte de la configuración de SSO del primer servidor, la cookie se envía junto con la solicitud. El servidor receptor intenta autenticar al usuario utilizando la señal de la cookie. Si se cumplen ambas condiciones, el servidor receptor valida la señal y crea un sujeto que se basa en el usuario en este servidor, sin pedir al usuario que vuelva a iniciar una sesión. Si la señal no puede validarse (por ejemplo, no se puede descifrar o no puede verificar la señal debido a una discrepancia de claves LTPA), se le solicitará al usuario que especifique la información de credenciales de nuevo.

Cualquier aplicación que se haya configurado para utilizar el atributo Form-login debe tener SSO para poder configurarse para ese servidor. Cuando el usuario se autentica para un form-login, la señal se vuelve a enviar al navegador que se utiliza para autorizar al usuario cuando se accede al recurso.

Consulte Personalización de la configuración de SSO utilizando cookies LTPA en Liberty.

Inicio de sesión único en el navegador web de SAML

El inicio de sesión único (SSO) del navegador web de SAML permite a las aplicaciones web delegar la autenticación de usuario a un proveedor de identidades SAML en lugar de un registro de usuarios configurado.

Para obtener más información sobre la configuración del inicio de sesión único (SSO) del navegador web de SAML en el servidor de Liberty, consulte Inicio de sesión único de navegador web SAML 2.0.

Autenticación conectable

Utilice las siguientes formas de personalizar el proceso de autenticación:

Si desea más información sobre el módulo de inicio de sesión JAAS y TAI, consulte Autenticación avanzada en WebSphere Application Server.

Confirmación de identidad

Además, la autenticación que requiere una entidad solicitante para probar su identidad, Liberty también da soporte a la aserción de identidad. Esta es una forma relajada de autenticación que no requiere una prueba de identidad, pero que acepta la identidad que se basa en una relación de confianza con la entidad que autoriza la identidad confirmada.

Utilice las formas siguientes de confirmar identidades en Liberty
  1. Utilice el inicio de sesión de tabla hash. Consulte Desarrollo de módulos de inicio de sesión personalizados JAAS para una configuración de inicio de sesión en el sistema.
  2. Utilice IdentityAssertionLoginModule. Puede permitir que una aplicación o un proveedor de sistema confirme una identidad con la validación de confianza. Para utilizar IdentityAssertionLoginModule, utilice la infraestructura de inicio de sesión JAAS, donde la validación de confianza se realiza en un módulo de inicio de sesión personalizado y la creación de credenciales se realiza en IdentityAssertionLoginModule. También puede utilizar los dos módulos de inicio de sesión para crear una configuración de inicio de sesión JAAS que puede utilizarse para confirmar una identidad.
    Se necesitan los dos módulos de inicio de sesión personalizados siguientes:
    El módulo de inicio de sesión implementado por el usuario (validación de confianza)
    El módulo de inicio de sesión implementado por el usuario realiza las acciones que requiere el usuario en la verificación de confianza. Cuando se verifica la confianza, el estado de la verificación de confianza y la identidad de inicio de sesión deben colocarse en una correlación en el estado compartido del módulo de inicio de sesión, para que el módulo de inicio de sesión de creación de credenciales pueda utilizar la información. Almacene esta correlación en la siguiente propiedad:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    Esta propiedad está formada por las siguientes propiedades:
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      Esta propiedad se establece en true si es de confianza y en false si no es de confianza.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      Esta propiedad contiene el principal de la identidad.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      Esta propiedad contiene el certificado de la identidad.
    Módulo de inicio de sesión de la confirmación de identidad (creación de credenciales)
    El siguiente módulo crea la credencial:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
    Este módulo se basa en que la información de estado de confianza en el estado compartido del contexto de inicio de sesión.
    El módulo de inicio de sesión de confirmación de identidad busca la información de confianza en la propiedad de estado compartido:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    Esta propiedad contiene el estado de confianza y la identidad para el inicio de sesión, y debe incluir la siguiente propiedad:
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      Esta propiedad se establece en true si es de confianza y en false si no es de confianza.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      Esta propiedad contiene el principal de la identidad para el inicio de sesión, si se utiliza un principal.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      Esta propiedad contiene una matriz de cadena de certificados que contiene la identidad para el inicio de sesión, si se utiliza un certificado.

    Si falta el estado, la confianza o la información de identidad, se devuelve el mensaje WSLoginFailedException. A continuación, el módulo de inicio de sesión inicia la sesión con la identidad, y el sujeto contiene la nueva identidad.

    Consulte Personalización del inicio de sesión de aplicaciones para realizar la confirmación de identidad utilizando JAAS.

Autenticación RunAs()

Cuando se haya autenticado satisfactoriamente después de invocar un servlet, el servlet puede realizar llamadas posteriormente, por ejemplo, a otros servlets. Estas llamadas posteriores normalmente se realizan bajo la misma identidad de seguridad que ha utilizado originalmente para iniciar la sesión en el servlet. Esta identidad se conoce como identidad de llamante. Como alternativa, puede optar por delegar en una identidad diferente mediante la especificación RunAs, para que las llamadas posteriores que realiza el servlet se ejecuten con esta otra identidad. En resumen, tiene dos opciones para propagar la identidad de seguridad:
  • Propagar la identidad del llamante, que es el comportamiento predeterminado.
  • Delegar la identidad RunAs que puede especificar utilizando la especificación RunAs.

Después de que el servidor autentica al usuario original, el servidor autentica al usuario RunAs. Si la autenticación falla, el servidor vuelve atrás para propagar la identidad del llamante.

Para utilizar la especificación RunAs, debe actualizar el descriptor de despliegue de la aplicación para que incluya el elemento run-as o la anotación @RunAs. Establezca este elemento en el rol de seguridad en el que desea delegar.

Consulte Configuración de la autenticación RunAs en Liberty.

Módulo de inicio de sesión de proxy

La clase del módulo de inicio de sesión de proxy carga el módulo de inicio de sesión del servidor de aplicaciones y delega todas las operaciones en la implementación del módulo de inicio de sesión real. La implementación del módulo de inicio de sesión real se especifica como la opción de delegación cuando se configuran las opciones. El módulo de inicio de sesión proxy es necesario ya que los cargadores de clases de aplicación no pueden ver los cargadores de clases de biblioteca compartida del producto de servidor de aplicaciones. Con un inicio de sesión programado por la aplicación que utiliza el método Login() de la clase LoginContext con el WSLogin de entrada de contexto de inicio de sesión JAAS, el módulo de inicio de sesión proxy delega todo el trabajo al system.DEFAULT de entrada de contexto de inicio de sesión JAAS.

Inicio de sesión de certificado

Con la característica de inicio de sesión de certificados, puede autenticar las solicitudes web, tales como los servlets, utilizando certificados X509 del lado del cliente, en lugar de proporcionar un ID de usuario y una contraseña.

La autenticación de certificados funciona asociando un usuario del registro de usuarios con el nombre distinguido del certificado de cliente de una solicitud web. La confianza se establece haciendo que el servidor confié en el certificado de cliente de confianza, por ejemplo, el firmante del certificado de cliente debe estar en el almacén de confianza del servidor. Este mecanismo elimina la necesidad de que los usuarios proporcionen una contraseña para establecer la confianza.

Consulte Protección de comunicaciones con Liberty.

Módulo de inicio de sesión de tabla hash

Busque los atributos necesarios en el registro de usuarios, ponga los atributos en una tabla hash y, a continuación, añada esta última al estado compartido. Si se cambia la identidad en este módulo de inicio de sesión, debe añadir la tabla hash al estado compartido. Si no se cambia la identidad, pero el valor del código requiresLogin es true, puede crear la tabla hash de atributos. No es necesario que cree una tabla hash en esta situación, ya que Liberty maneja el inicio de sesión automáticamente. Sin embargo, es aconsejable que considere crear una tabla hash para recopilar los atributos en casos especiales. Por ejemplo, si está utilizando su propio registro de usuarios especial, crear una implementación de UserRegistry, utilizando una tabla hash, y dejar que el servidor recopile los atributos de usuario automáticamente podría ser una solución sencilla.

Las reglas siguientes definen más detalladamente cómo se completa un inicio de sesión de tabla hash. Debe utilizar un objeto java.util.Hashtable en el sujeto (conjunto de credenciales públicas o privadas) o HashMap de estado compartido. La clase com.ibm.wsspi.security.token.AttributeNameConstants define las claves que contienen la información de usuario. Si el objeto Hashtable se ha colocado en el estado compartido del contexto de inicio de sesión utilizando un módulo de inicio de sesión personalizado que aparece listado antes del módulo de inicio de sesión con tabla hash, se busca el valor del objeto java.util.Hashtable utilizando la clave siguiente dentro del hashMap de estado compartido:

Propiedad
com.ibm.wsspi.security.cred.propertiesObject
Referencia a la propiedad
AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
Descripción
Esta clave busca el objeto de tabla hash que contenga las propiedades necesarias en el estado compartido del contexto de inicio de sesión:
Resultado esperado
Un objeto java.util.Hashtable.

Si un objeto java.util.Hashtable se encuentra en el sujeto o en el área de estado compartido, verifique que las siguientes propiedades estén presentes en la tabla hash:

  • com.ibm.wsspi.security.cred.uniqueId
    Referencia a la propiedad
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    Devuelve
    java.util.String
    Descripción
    El valor de la propiedad debe ser una representación exclusiva del usuario. Para la implementación predeterminada de Liberty, esta propiedad representa la información que está almacenada en la configuración de autorización de aplicación. La información está ubicada en el descriptor de despliegue de aplicaciones después de que se despliegue y se realice la correlación de usuarios con roles. Consulte los ejemplos de formato esperados si la correlación de usuarios con roles se realiza consultando en una implementación de registro de usuarios de Liberty.
    Formatos de ejemplo esperados
    Tabla 1. Ejemplos de formato de uniqueId. En esta tabla se ofrecen ejemplos del formato esperado.
    Registro de usuario Valor de formato (UniqueUserId)
    LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use
    Básico basicRegistryRealm/kelvin
    La propiedad com.ibm.wsspi.security.cred.uniqueId es necesaria.
  • com.ibm.wsspi.security.cred.securityName
    Referencia a la propiedad
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    Devuelve
    java.util.String
    Descripción
    Esta propiedad busca securityName del usuario de autenticación. Este nombre generalmente recibe el nombre de nombre de visualización o nombre abreviado. Liberty utiliza el atributo securityName para las API (interfaces de programación de aplicaciones) getRemoteUser, getUserPrincipal y getCallerPrincipal. Para garantizar la compatibilidad con la implementación predeterminada del valor de securityName, llame al método public String getUserSecurityName(String uniqueUserId) UserRegistry.
    Formatos de ejemplo esperados
    Tabla 2. Ejemplos de formato de securityName. En esta tabla se ofrecen ejemplos del formato esperado.
    Registro de usuario Valor de formato (securityName)
    LDAP kevin
    Básico kevin
    La propiedad com.ibm.wsspi.security.cred.securityname es necesaria.
  • com.ibm.wsspi.security.cred.group
    Referencia a la propiedad
    AttributeNameConstants. WSCREDENTIAL_GROUP
    Devuelve
    java.util.ArrayList
    Descripción
    Esta clave busca la lista de matrices de los grupos a los que pertenece el usuario. Los grupos están especificados en el formato nombre_reino/nombre_usuario. El formato de estos grupos es importante, ya que el motor de autorización de Liberty utiliza los grupos para las correlaciones de grupos con roles en el descriptor de despliegue. El formato que se proporciona debe coincidir con el formato previsto por la implementación predeterminada de Liberty. Cuando utilice un proveedor de autorizaciones de terceros, debe utilizar el formato esperado por el proveedor de terceros. Para garantizar la compatibilidad con la implementación predeterminada del valor de los ID de grupo únicos, llame al método public List getUniqueGroupIds(String uniqueUserId) UserRegistry.
    Formatos de ejemplo esperados
    Tabla 3. Ejemplos de formato de grupo. En esta tabla se proporcionan algunos ejemplos de formato cuando se configura la correlación de identidad de entrada.
    Registro de usuario Valor de formato (group)
    LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US
    Básico basicRegistryRealm/group1
    La propiedad com.ibm.wsspi.security.cred.group es necesaria. No es necesario que un usuario esté asociado con grupos.
  • [16.0.0.3 and later]com.ibm.wsspi.security.cred.realm
    Referencia a la propiedad
    AttributeNameConstants. WSCREDENTIAL_REALM
    Devuelve
    java.util.String
    Descripción
    Esta propiedad clave puede especificar el nombre de reino del registro de usuarios que está almacenado en la cookie LTPA.
    Esta propiedad clave no es necesaria.
  • com.ibm.wsspi.security.cred.cacheKey
    Referencia a la propiedad
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    Devuelve
    java.lang.Object
    Descripción
    Esta propiedad de claves puede especificar un objeto que represente las propiedades exclusivas del inicio de sesión, incluidos la información específica de usuario y los atributos dinámicos de usuario que puedan afectar a la exclusividad. Por ejemplo, cuando el usuario se conecte desde la ubicación A, que podría afectar al control de acceso, la clave de memoria caché debe incluir la ubicación A para que el sujeto recibido sea el sujeto correcto para la ubicación actual.
    Esta propiedad com.ibm.wsspi.security.cred.cacheKey no es necesaria. Cuando no se especifica esta propiedad, la búsqueda de memoria caché es el valor especificado para WSCREDENTIAL_UNIQUEID. Cuando esta información se encuentra en el objeto java.util.Hashtable, Liberty crea un sujeto similar al sujeto que pasa por el proceso normal de inicio de sesión, al menos para LTPA. El nuevo sujeto contiene un objeto WSCredential y un objeto WSPrincipal que se ha llenado por completo con la información que se encuentra en el objeto Hashtable.

Icono que indica el tipo de tema Tema de concepto



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=cwlp_authentication
Nombre de archivo:cwlp_authentication.html