Configuración de comunicaciones de entrada de Common Secure Interoperability Versión 2

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

  1. Inicie la consola administrativa.
  2. Pulse Seguridad > Seguridad global.
  3. En Seguridad RMI/IIOP, pulse Comunicaciones de entrada CSIv2.
  4. 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][IBM i]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]
      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 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][IBM i]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.

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

  5. Cuando decida qué tipo de autenticación ha de aceptar, tenga en cuenta lo siguiente:
    • Un servidor puede recibir simultáneamente varias capas, por lo tanto, una norma de orden de prioridad decide qué identidad se ha de utilizar. La capa de aserción de identidad tiene la prioridad más alta. A continuación le sigue la capa de mensajes, y la capa de transporte tiene la prioridad más baja. La autenticación de certificados de cliente SSL se utiliza cuando es la única capa proporcionada. Si se proporcionan la capa de mensajes y la capa de transporte, se utiliza la capa de mensajes para establecer la identidad para la autorización. La capa de aserción de identidad se utiliza para establecer la prioridad, cuando se proporciona.
    • ¿Recibe habitualmente este servidor las solicitudes desde un cliente o desde un servidor, o desde ambos? Si el servidor recibe siempre las solicitudes desde un cliente, no es necesaria la aserción de identidad. Puede seleccionar la capa de mensajes, la capa de transporte o ambas. También puede decidir cuándo es necesaria la autenticación o cuándo está soportada. Para seleccionar una capa como necesaria, el cliente de envío debe suministrar esta capa o se rechazará la solicitud. No obstante, si la capa sólo está aceptada, ésta puede no suministrarse.
    • ¿Qué tipo de identidad de cliente se ha suministrado? Si la identidad del cliente es la autenticación de certificados de cliente y desea que la cadena de certificados fluya en sentido descendente para que se correlacione con los registros de usuario del servidor en sentido descendente, la aserción de identidad es la opción adecuada. La aserción de identidad conserva el formato del cliente de origen. Si el cliente de origen se ha autenticado con el ID de usuario y la contraseña, se enviará una identidad de principal. Si la autenticación se efectúa con un certificado, se enviará la cadena de certificados.

      [AIX Solaris HP-UX Linux Windows][IBM i]En algunos casos, si el cliente se ha autenticado con un símbolo y el registro de usuario es un servidor LDAP (Lightweight Directory Access Protocol), se enviará un DN (Nombre distinguido).

  6. 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 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
  7. 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).

Icon that indicates the type of topic Task topic



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