Aserción de identidad en el servidor en sentido descendente
Cuando un cliente se autentica ante un servidor, se establece la credencial recibida. Cuando el motor de autorización comprueba la credencial para determinar si se le permite acceso, también establece la credencial de invocación. La confirmación de identidad es la credencial de invocación que se comprueba en el servidor situado en sentido descendente.
Cuando un cliente se autentica ante un servidor, se establece la credencial recibida. Cuando el motor de autorización comprueba la credencial para determinar si se le permite acceso, también establece la credencial de invocación, de modo que si el método EJB (Enterprise JavaBeans) llama a otro método EJB situado en otros servidores, la credencial de invocación puede ser la identidad utilizada para iniciar el método en sentido descendente. Dependiendo de la modalidad RunAs para enterprise beans, la credencial de invocación se establecerá como la identidad del cliente de origen, la identidad del servidor o una identidad diferente especificada. Independientemente de la entidad que se establezca, cuando está habilitada la confirmación de identidad, se comprueba la credencial de invocación en el servidor situado en sentido descendente.
La identidad de la credencial de
invocación se envía al servidor situado en sentido descendente en una señal de
identidad. Además, cuando la autenticación básica
está habilitada, en la señal de autenticación del cliente se envía la identidad
del servidor emisor incluido la contraseña o la señal. La identidad del servidor
emisor se envía a través de una autenticación de certificado de cliente SSL (Capa de
sockets seguros) cuando la autenticación de certificados de cliente está habilitada. La autenticación básica tiene prioridad sobre la autenticación de
certificado de cliente.
- La identidad del servidor emisor enviada al servidor receptor es una señal GSSUP (ID de usuario y contraseña) o un certificado de cliente SSL. En z/OS, se envía el ID de tarea iniciada de MVS en lugar de la señal GSSUP cuando el registro de usuarios activo es el sistema operativo local y la autorización SAF está habilitada.
- La confianza se establece entre el servidor emisor y receptor en función de la identidad que se está enviando.
- Cuando se envía una señal GGSUP, la confianza se establece verificando si la identidad del servidor emisor está en la lista de principales de confianza del servidor receptor.
- Cuando se envía el ID de tarea iniciada de MVS, la confianza se establece verificando que el ID tiene la autoridad UPDATE en el perfil CB.BIND.<nombre_servidor> en la base de datos de SAF.
- Cuando se envía un certificado de cliente SSL, en z/OS este certificado se correlaciona con un ID de usuario SAF (Service Access Facility). La confianza se establece mediante verificando si este ID de usuario tiene autorización UPDATE para el perfil CB.BIND.<nombre_servidor>.
- Una vez se ha determinado que el servidor emisor está en la lista de confianza, el servidor autentica el servidor emisor para confirmar su identidad.
- El servidor se autentica comparando el ID de usuario y la contraseña del servidor emisor con los del servidor receptor. Si las credenciales del servidor emisor se autentican y son de confianza, el servidor procede a evaluar la señal de identidad.
- El servidor receptor comprueba su registro de usuarios definido para la presencia del ID de usuario confirmado a fin de recopilar información adicional sobre credenciales para fines de autorización (por ejemplo, pertenencias de grupo). Por lo tanto, el registro de usuarios del servidor receptor debe contener todos los ID de usuario confirmados. De lo contrario, la aserción de identidades no será posible. En un servidor con estado, esta acción se produce una vez para el par de servidor remitente y servidor receptor cuando las señales de identidad son las mismas. Las
solicitudes posteriores se realizarán mediante un ID de sesión.Nota: Si el servidor en sentido descendente no tiene un registro de usuarios con acceso a los ID de usuario confirmados en este repositorio, no utilice la confirmación de identidades, porque las comprobaciones de autorización fallarían. Al inhabilitar la confirmación de identidad, las comprobaciones de autorización del servidor receptor dejan de ser necesarias.
El servidor de destino valida la
autorización del servidor emisor para comprobar una identidad mediante el
certificado de cliente. El certificado de cliente se correlaciona con un ID de usuario SAF (Service Access Facility), ya sea utilizando los filtros de
MAP RACDCERT o los filtros RACMAP definidos en la base de datos de SAF. El ID de usuario SAF debe tener autorización para el
perfil CB.BIND.<optionSAFProfilePrefix>.cluster_short_name en la clase CBIND. Si no se envía un certificado de cliente, se realiza la
comprobación de CBIND con el ID de tarea iniciada del servidor emisor.
- Nombre de principal
- Nombre distinguido
- Cadena de certificados
- Identidad anónima
Una vez comprendido y analizado el formato de la identidad, ésta simplemente se correlaciona con una credencial. Para una señal de identidad ITTPrincipal, esta identidad tiene una correlación unívoca con los campos de ID de usuario.
Para una
señal de identidad ITTDistinguishedName, la correlación depende del
registro de usuarios. Para LDAP (Lightweight Directory Access Protocol), el filtro de búsqueda configurado determina
cómo se lleva a cabo la correlación. En LocalOS, el primer atributo del nombre distinguido (DN), que normalmente coincide
con el nombre común, se correlaciona con el ID de usuario del registro.
Las señales de identidad
ITTDistinguishedName y las señales de identidad ITTCertChain se
correlacionan de la misma forma. Ambos tipos de señales de identidad
utilizan un certificado correlacionado con un ID de usuario SAF utilizando
las funciones de correlación RACDCERT o equivalentes, como filtros RACMAP. La correlación se
puede basar en el nombre de Sujeto o el nombre de Emisor.
La confirmación de identidad sólo está
disponible utilizando el protocolo CSIv2 (Common Secure Interoperability Versión 2).