Las comunicaciones de entrada hacen referencia a la
configuración que determina el tipo de autenticación aceptada para las
solicitudes de entrada.
Esta autenticación se anuncia en la IOR (Interoperable Object Reference) que el
cliente recupera del servidor de nombres.
Procedimiento
- Inicie la consola administrativa.
- Pulse Seguridad > Seguridad global.
- En Seguridad RMI/IIOP, pulse Comunicaciones de entrada CSIv2.
- Consideremos las siguientes capas de seguridad:
- Aserción de identidad (capa de atributos).
Cuando esta opción está seleccionada, este servidor acepta señales de identidad de servidores en
sentido ascendente. Si el servidor recibe una señal de identidad, la identidad se toma de un cliente
de origen.
Por ejemplo, la identidad tiene el mismo formato que el cliente de origen ha
presentado al primer servidor. Un servidor emisor envía la identidad del cliente de origen. El formato de la identidad puede ser un nombre principal, un nombre distinguido o una cadena de certificados. En algunos casos, la identidad es anónima. Es importante confiar en el servidor emisor que envía la señal de identidad, ya que la identidad se autentica en este servidor. La confianza del servidor emisor se
establece ya sea utilizando la autenticación de certificados cliente SSL (Secure Sockets Layer)
o la autenticación básica. Debe seleccionar una de las dos capas de autenticación
en las dos autenticaciones, de entrada y salida, cuando selecciona la aserción de identidad.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
El ID de servidor se envía en el símbolo de
autenticación del cliente conjuntamente con el símbolo de identidad.
El ID de servidor se comprueba en la lista de los ID de servidores de confianza. Si el ID de servidor está en la lista de servidores de confianza, el ID de servidor se autentica.
Si el ID de servidor es válido, el símbolo de identidad se coloca en una
credencial y se utiliza para la autorización de solicitudes.
![[z/OS]](../images/ngzos.gif)
Nota: Si el registro que ha configurado es un sistema operativo local, la confianza se establece en su lugar comprobando si la identidad de servidor emisor se autoriza en el servidor receptor con autoridad UPDATE a la clase CBIND, perfil CB.BIND.<optionalSAFProfilePrefix>.<nombre_abreviado_clúster>. La identidad del servidor en sentido ascendente se envía con un certificado de cliente SSL. Si no se utiliza SSL, se realiza la comprobación de CBIND con la identidad de la tarea iniciada del servidor en sentido ascendente.
Avoid trouble: Cuando la aserción de identidad está habilitada, la capa de mensajes o la capa de transporte también debe estar habilitada.
Para la comunicación entre servidores, además de habilitar la capa de
transporte/autenticación de cliente, también se debe habilitar la aserción de
identidad o capa de mensajes.
gotcha
Para obtener más información, consulte
Aserción de identidad.
- Capa de mensajes:
Autenticación básica (GSSUP):
Este tipo de autenticación es la más típica. Se envía el ID de usuario y contraseña o el símbolo autenticado desde un
cliente puro o desde un servidor en sentido ascendente. Cuando se recibe un ID de usuario y contraseña en el servidor, se autentican con el registro de usuario del servidor en sentido descendente.
Lightweight
Third Party Authentication (LTPA):
En este caso, se envía una señal LTPA desde el servidor en sentido ascendente.
Si selecciona LTPA, ambos servidores deben compartir las mismas claves LTPA
Kerberos (KRB5):
Para seleccionar Kerberos, el mecanismo de autenticación activo debe ser Kerberos. En este caso, se envía una señal Kerberos
desde el servidor emisor.
Para obtener más información, lea acerca de la autenticación de capa de mensajes.
- Autenticación de certificados de cliente SSL (Secure Sockets
Layer) (capa de transporte).
El certificado de cliente SSL se utiliza para la
autenticación, en lugar del ID de usuario y la Contraseña. Si un servidor delega una identidad a un servidor receptor, ésta vendrá de la capa de mensajes (un símbolo de autenticación
de cliente) o la capa de atributos (una señal de identidad), y no desde la capa de
transporte a través de la autenticación de certificado de cliente.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Un cliente tiene un certificado de cliente SSL guardado en el archivo de almacén de
claves de la configuración cliente. Cuando la
autenticación de cliente SSL está habilitada en este servidor, el servidor
solicita al cliente que envíe el certificado de cliente SSL cuando se
establezca la conexión. La cadena de certificados está disponible en el socket siempre que se envía una solicitud al servidor. El interceptor de solicitudes del servidor obtiene la cadena de certificados del
socket y la correlaciona con un usuario del registro de usuario. Este tipo de
autenticación es óptimo para la comunicación directa desde un cliente a un servidor.
Pero cuando el flujo de comunicación es descendente, la identidad normalmente
circula por la capa de mensajes o mediante la aserción de identidad.
Un cliente tiene un certificado de cliente SSL guardado en el
archivo de anillo de claves de la configuración cliente. Cuando la
autenticación de cliente SSL está habilitada en este servidor, el servidor
solicita al cliente que envíe el certificado de cliente SSL cuando se
establezca la conexión. La cadena de certificados está disponible en el socket siempre que se envía una solicitud al servidor. El interceptor de solicitudes del servidor obtiene la cadena de certificados del
socket y la correlaciona con un usuario del registro de usuario. Este tipo de
autenticación es óptimo para la comunicación directa desde un cliente a un servidor. Sin embargo, cuando tiene que ir en sentido descendente,
la identidad fluye normalmente en la capa de mensajes o a través de la aserción de identidad.
- Cuando decida qué tipo de autenticación ha de aceptar, tenga en cuenta lo siguiente:
- Configure una lista
de servidores de confianza. Si selecciona la aserción de identidad para
solicitudes de entrada, inserte una lista de los ID de administrador de servidor
separados por barra vertical (|) en los que este servidor puede dar soporte a la sumisión
de señales de identidad. Para obtener compatibilidad con versiones anteriores, todavía puede utilizar listas delimitadas por comas. No obstante, si el ID de servidor es un nombre distinguido (DN), deberá
utilizar una lista delimitada por barras verticales (|), porque el
delimitador de coma no funciona. Si opta por dar soporte a todos los servidores que envíen una señal de
identidad, puede escribir un asterisco (*) en este campo. Esta acción se denomina confianza asumida previamente. En este caso, utilice la autenticación de certificado cliente SSL entre servidores para establecer la confianza.
Supported configurations: Este paso se aplica si utiliza LDAP (Lightweight Directory Access Protocol) o un registro
de usuarios personalizado.
No obstante, no será aplicable cuando se utiliza el registro de usuarios de sistema
operativo local o un registro de usuarios SAF (System Authorization Facility).
sptcfg
- Configure la gestión de sesiones. Puede elegir si desea la seguridad con o sin estado.
El rendimiento es óptimo si se selecciona sesiones con estado. La primera solicitud de método entre un cliente y un servidor se autentica. Todas las solicitudes subsiguientes (o hasta que expira la señal de credenciales) volverán a utilizar la información de sesión incluida la credencial. Un cliente enviará un ID de contexto para las solicitudes subsiguientes. El ID de contexto tiene el ámbito en la conexión a afectos de exclusividad.
Resultados
Cuando haya finalizado de configurar este panel, habrá configurado la mayor
parte de la información que el cliente recopila al determinar qué ha de enviar a
este servidor. Una configuración de salida de cliente o servidor junto con esta configuración de entrada de servidor, determinarán la seguridad que se aplica. Cuando sabe qué clientes enviarán solicitudes, la configuración es sencilla. Sin embargo, si tiene un grupo dispar de clientes con diferentes requisitos de seguridad, el servidor tendrá en cuenta varias capas de autenticación.
Para un servidor de aplicaciones de Java Platform, Enterprise Edition, el método de
autenticación elegido suele ser aserción de identidad o capa de mensajes, pues se
desea que la identidad del cliente de origen se delegue en sentido descendente. No
es posible delegar fácilmente un certificado de cliente utilizando una conexión SSL.
Es aceptable habilitar la capa de transporte para obtener una seguridad de servidor
adicional, pues la porción adicional del certificado de cliente correspondiente al
protocolo SSL añade algo de carga de trabajo al establecimiento de la conexión SSL.
Qué hacer a continuación
Después de determinar el tipo de datos de autenticación que puede
recibir este servidor, puede determinar qué se ha de seleccionar para la
seguridad de salida. Para obtener más información, consulte el artículo
Configuración de la
autenticación de salida CSIv2 (Common Secure Interoperability Versión 2).