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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

El servidor receptor necesita ambas señales de identidad para aceptar la identidad evaluada. El servidor receptor realiza las siguientes acciones para aceptar la identidad evaluada:
  • 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.
    1. 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.
    2. 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.
    3. 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.

[z/OS]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.

La evaluación de la señal de identidad consta de estos cuatro formatos de identidad que existen en una señal de identidad:
  • Nombre de principal
  • Nombre distinguido
  • Cadena de certificados
  • Identidad anónima
Los servidores del producto que reciben información de autenticación, generalmente dan soporte a los cuatro tipos de identidades. El servidor emisor decide cual se seleccionará, según cómo se haya autenticado el cliente original. El tipo existente dependerá de cómo se autentica originalmente al cliente ante el servidor emisor. Por ejemplo, si el cliente utiliza la autenticación de cliente SSL (Secure Sockets Layer) para autenticar al servidor emisor, la señal de identidad enviada al servidor en sentido descendente contendrá la cadena de certificados. Con esta información, el servidor receptor puede realizar su propia correlación de la cadena de certificados, lo que se incrementa la interoperatividad con otros proveedores y plataformas.

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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]La confirmación de identidad sólo está disponible utilizando el protocolo CSIv2 (Common Secure Interoperability Versión 2).

Nota: Existe una restricción para utilizar la aserción de identidad con la señal KRB en sentido descendente. Si utiliza la aserción de identidad con Kerberos habilitado, la aserción de identidad no tiene la señal de autenticación de Kerberos (KRBAuthnToken) al ir a los servidores en sentido descendente. En lugar de ello, utiliza LTPA para la autenticación.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_csiv2ida
File name: csec_csiv2ida.html