Utilice esta página para especificar las características que soporta un servidor para un cliente que esté accediendo a sus recursos.
Para ver esta página de la consola administrativa, pulse Seguridad > Protocolo de autenticación > Autenticación de entrada CSI.
Los valores de autenticación de entrada CSI sirven para configurar el tipo de información de autenticación contenida en un transporte o petición de entrada.
Las características de autenticación incluyen tres capas de autenticación, que se pueden utilizar de forma simultánea:
Pestaña Configuración
En la capa de mensajes, se realiza la autenticación básica (ID de usuario/contraseña). Este tipo de autenticación consiste, generalmente, en enviar un ID de usuario y una contraseña del cliente al servidor para autenticarlos. Esto implica también delegar un símbolo de credencial desde una credencial ya autenticada, siempre que se pueda enviar ese tipo de credencial (por ejemplo, LTPA (Lightweight Third Party Authentication)). Si Autenticación básica está seleccionada para el servidor, especifique tanto la autenticación de ID de usuario y contraseña como la autenticación basada en símbolos.
Cuando seleccione Autenticación básica, debe decidir si es Necesaria o Soportada. Si selecciona Necesaria, sólo tienen permiso para invocar peticiones en el servidor los clientes que estén configurados para autenticarse en este servidor a través de la capa de mensajes. Si selecciona soportada, se indica que este servidor acepta la Autenticación básica. No obstante, se pueden utilizar otros métodos de autenticación si están configurados y se aceptan las peticiones anónimas. Si selecciona Nunca, este servidor no estará configurado para aceptar la autenticación de capa de mensajes de ningún cliente.
| Tipo de datos: | String |
En la capa de transporte, se lleva a cabo la autenticación de certificado de cliente SSL (Secure Sockets Layer). En la capa de mensajes, se realiza la autenticación básica (ID de usuario/contraseña). La autenticación de certificados de cliente normalmente funciona mejor que la autenticación de capa de mensajes, aunque requiere algunos pasos de configuración adicionales. Estos pasos adicionales conllevan asegurarse de que el servidor disponga del certificado de firmante de cada cliente al que esté conectado. Si el cliente utiliza una autoridad certificadora (CA) para crear el certificado personal, sólo se necesita el certificado raíz de la CA de la sección de firma del servidor del archivo de confianza SSL. Cuando el certificado se autentica en un registro de usuarios LDAP (Lightweight Directory Access Protocol), el nombre distinguido (DN) se correlaciona según el filtro especificado al configurar LDAP. Cuando el certificado se autentica en un Registro de usuario de sistema operativo local, el primer atributo del DN del certificado (normalmente el nombre común) se correlaciona con el ID de usuario del registro. La identidad de los certificados de cliente sólo se utiliza si no se presenta ninguna otra capa de autenticación al servidor.
Cuando seleccione Autenticación de certificados de cliente, debe decidir si es Necesaria o Soportada. Si selecciona Necesaria, sólo tienen permiso para invocar peticiones en el servidor los clientes que estén configurados para autenticarse en este servidor a través de certificados de cliente SSL. Si selecciona Soportada, este servidor acepta la autenticación de certificados de cliente SSL, aunque se pueden utilizar otros métodos de autenticación (si están configurados) y se aceptarán peticiones anónimas. Si selecciona Nunca, este servidor no estará configurado para aceptar la autenticación de certificados de cliente de ningún cliente.
| Tipo de datos | String |
La confirmación de identidad se efectúa en la capa de atributos y sólo se puede aplicar en servidores. El principal determinado en el servidor se basa en las reglas de precedencia. Si se realiza la confirmación de identidad, la identidad siempre se deriva del atributo. Si se realiza la autenticación básica sin la confirmación de identidad, la identidad siempre se deriva de la capa de mensajes. Por último, si se realiza la autenticación de certificados de cliente SSL sin la autenticación básica ni la confirmación de identidad, la identidad se deriva de la capa de transporte.
La identidad confirmada es la credencial de invocación que determina la modalidad RunAs para el enterprise bean. Si la modalidad RunAs es Cliente, la identidad es la identidad del cliente. Si la modalidad RunAs es Sistema, la identidad es la identidad del servidor. Si la modalidad RunAs es Especificada, la identidad es la que está especificada. El servidor receptor recibe la identidad en un símbolo de identidad, y también recibe la identidad del servidor emisor en un símbolo de autenticación de cliente. El servidor receptor valida la identidad del servidor emisor como una identidad de confianza mediante el recuadro de entrada ID de servidor de confianza. Entre una lista de nombres de principal separados por comas, por ejemplo IDservidor1, IDservidor2, IDservidor3.
Al autenticarse en un registro de usuario LocalOS, todos los tipos de símbolos de identidad se correlacionan con el campo de ID de usuario del registro de usuario activo. Para un símbolo de identidad ITTPrincipal, se correlaciona de uno en uno con los campos de ID de usuario. Para un símbolo de identidad ITTDistinguishedName, el valor del primer signo igual se correlaciona con el campo del ID de usuario. Para un símbolo de identidad ITTCertChain, el valor del primer signo igual del nombre distinguido se correlaciona con el campo de ID de usuario.
Al autenticarse en un registro de usuarios LDAP, los filtros LDAP determinan cómo se correlaciona una identidad de tipo ITTCertChain y ITTDistinguishedName con el registro. Si el tipo de símbolo es ITTPrincipal, el principal se correlaciona con el campo UID del registro LDAP.
| Tipo de datos: | String |
Utilice esta lista para decidir si se trata de un servidor de confianza. Incluso si el servidor está en la lista, el servidor emisor deberá autenticarse con el servidor receptor para poder aceptar el símbolo de identidad del servidor receptor.
| Tipo de datos | String |
El primer contacto entre un cliente y un servidor debe autenticarse completamente. Sin embargo, todos los demás contactos con sesiones válidas, vuelven a utilizar la información de seguridad. El cliente pasa un ID de contexto al servidor y el ID se utiliza para buscar la sesión. El ID de contexto tiene el ámbito de la conexión, lo cual garantiza la exclusividad. Cuando la sesión de seguridad no es válida y el reintento de autenticación está habilitado (por omisión), el interceptor de seguridad del cliente invalida la sesión del cliente y vuelve a someter la petición sin que el usuario lo sepa. Esto puede producirse si la sesión no existe en el servidor (el servidor ha fallado y ha reanudado la operación). Cuando se inhabilita este valor, cada una de las invocaciones de método deben reautenticarse.
| Tipo de datos | String |