Protocolo de autenticación para la seguridad de EJB
Los servidores WebSphere Application
Server Versión 9.0 sólo dan soporte al protocolo de autenticación CSIv2.SAS sólo recibe soporte
entre los servidores de la versión 6.0.x y anteriores que se hayan
federado en una célula de Versión 9.0. La
opción de seleccionar SAS y/o CSIv2 sólo está disponible en la consola de
administración cuando se ha federado un release de la Versión 6.0.x o
anterior en una célula de
Versión 9.0.
z/SAS sólo recibe
soporte entre los servidores de la versión 6.0.x y anteriores que se hayan
federado en una célula de
Versión 9.0. La posibilidad de optar entre
z/SAS, CSIv2, o ambas sólo está disponible en la consola de administración cuando una
versión 6.0.x o release anterior se haya federado en una célula de la Versión
6.1.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
La invocación de métodos EJB (Enterprise Java™ Beans) en un entorno seguro de WebSphere Application Server necesita un protocolo de autenticación que determine el nivel de seguridad y el tipo de autenticación que hay entre un cliente y un servidor específicos para cada solicitud. Durante la invocación del método el protocolo de autenticación se encarga de fusionar los requisitos de autenticación del servidor que se determinan mediante la Referencia de objeto interoperativa (IOR) del objeto con los requisitos de autenticación del cliente que se determinan mediante la configuración del cliente y generar una política de autenticación específica para esta pareja de cliente y servidor.
- ¿Qué tipo de conexión puede realizar con este servidor: SSL (Secure Sockets Layer) o TCP/IP?
- Si se selecciona SSL, ¿cuál es el nivel de cifrado de los datos?
- Si selecciona SSL, ¿autenticará el cliente mediante certificados de cliente?
- ¿Autenticará el cliente utilizando el ID de usuario y la contraseña? ¿Existe alguna credencial previamente?
- ¿Confirma la identidad del cliente a los servidores que se encuentran en sentido descendente?
- Dada la configuración del cliente y del servidor, ¿puede continuarse con una solicitud segura?
Puede configurar los dos protocolos (SAS y
CSIv2) para que trabajen simultáneamente. Si un servidor da soporte a ambos
protocolos, exporta una IOR con componentes codificados que describen la
configuración para SAS y CSIv2. Si un cliente da soporte a
ambos protocolos, lee los componentes codificados para CSIv2 y SAS. Si el cliente da soporte a ambos protocolos y el servidor también, se
utilizará CSIv2. Sin embargo, si el servidor da
soporte a SAS (por ejemplo, si es un release anterior de WebSphere Application
Server) y el cliente da soporte a ambos protocolos, el cliente seleccionará SAS para
esta solicitud, ya que el protocolo SAS es lo que tienen en común.
Puede configurar los dos protocolos (z/SAS y
CSIv2) para que trabajen simultáneamente. Si un servidor da soporte a ambos
protocolos, exporta una IOR con componentes codificados que describen la
configuración para z/SAS y CSIv2. Si un cliente da soporte a ambos protocolos, lee
los componentes codificados para CSIv2 y z/SAS.
Si el cliente da soporte a ambos protocolos y el servidor también, se
utilizará CSIv2. Sin embargo, si el servidor da soporte a z/SAS (por ejemplo, si es
un release anterior de WebSphere Application Server) y el cliente da soporte a ambos
protocolos, el cliente seleccionará z/SAS para esta solicitud, ya que el protocolo
z/SAS es lo que tienen en común.
Se considera que CSIv2 está habilitado
en el cliente si existe la propiedad Java com.ibm.CORBA.ConfigURL. Si la propiedad no está
especificada o no existe, CSIv2 no está habilitado.
Elija un protocolo
especificando la propiedad com.ibm.CSI.protocol en el cliente y configúrelo
mediante la consola administrativa en el servidor. En los artículos de propiedades
de SAS y CSIv2 se proporciona más información.
Common Secure Interoperability Specification, Versión 2
CSIv2 (Common Secure Interoperability Specification, Versión 2) define el
SAS (Security Attribute Service) que permite la autenticación
interoperable, la delegación y los privilegios. Los protocolos CSIv2 SAS y SAS son completamente diferentes. CSIv2 SAS es un
subcomponente de CSIv2 que da soporte a SSL y a la interoperatividad con la
especificación EJB, versión 2.1.
CSIv2 (Common
Secure Interoperability Specification, Versión 2) define el SAS (Security Attribute
Service) que permite la autenticación interoperable y la delegación. Los protocolos CSIv2 y z/SAS son completamente diferentes.
CSIv2 SAS es un
subcomponente de CSIv2 que da soporte a SSL y a la interoperatividad.
Security Attribute Service
El protocolo Common Secure Interoperability Specification Versión 2, Security Attribute Service (CSIv2 SAS) está diseñado para intercambiar elementos de protocolo en el contexto de servicio de la solicitud GIOP (General Inter-ORB Protocol) y en los mensajes de respuesta que se comunican a través de un transporte basado en conexión. El protocolo está especialmente indicado para los entornos en los que se utiliza la seguridad de la capa de transporte como, por ejemplo, la disponible a través de SSL (Secure Sockets Layer) y TLS (Transport Layer Security), para proporcionar seguridad de mensajes (es decir, integridad y confidencialidad) y autenticación de servidor a cliente. El protocolo proporciona funciones de autenticación de clientes, delegación y privilegios que pueden aplicarse para superar las deficiencias correspondientes de un transporte subyacente. El protocolo CSIv2 SAS permite funciones de interoperatividad ofreciendo el servicio como el protocolo de nivel superior con el que se unifican los transportes seguros.
Interceptores de conexiones y solicitudes
Los protocolos de autenticación que utiliza WebSphere Application Server son los servicios IIOP (Interoperable Inter-ORB Protocol). IIOP es un protocolo de comunicaciones de solicitud y respuesta que se utiliza para enviar mensajes entre dos ORB (Object Request Broker). Cada solicitud que realiza un ORB cliente a un ORB servidor, el ORB servidor devuelve una respuesta asociada al ORB cliente. Antes de que se produzca ningún flujo de solicitud, debe establecerse una conexión entre el ORB cliente y el ORB servidor a través del transporte TCP/IP (SSL es una versión segura de TCP/IP). El ORB cliente invoca el interceptor de conexiones de clientes del protocolo de autenticación, que se utiliza para leer los componentes codificados de la IOR del objeto ubicado en el servidor. Como se ha mencionado anteriormente, aquí es donde se establece la política de autenticación para la solicitud. Dependiendo de la política de autenticación, (una fusión de la configuración del servidor con la configuración del cliente), se devuelve al ORB la potencia de la conexión. El ORB efectúa la conexión adecuada, generalmente, a través de SSL.
Después de establecerse la conexión, el ORB del cliente invoca el interceptor de solicitudes de clientes del protocolo de autenticación, el cual se utiliza para enviar información de seguridad que no sea la establecida por el transporte. La información de seguridad incluye la señal de ID de usuario y contraseña autenticado por el servidor, una señal específica del mecanismo de autenticación validada por el servidor o una señal de aserción de identidad. La aserción de identidad es un método mediante el cual un servidor confía en otro servidor sin que sea necesario volver a autenticar o validar al cliente que origina la solicitud. Sin embargo, es necesario algún procedimiento más para que el servidor confíe en el servidor en sentido ascendente. Esta información de seguridad adicional se envía con el mensaje en un contexto de servicio. Un contexto de servicio tiene un identificador registrado, de modo que el ORB del servidor puede identificar el protocolo que está enviando la información.
El que un contexto de
servicio contenga una identidad exclusiva es otra de las razones por las
que WebSphere Application Server da soporte a SAS y CSIv2 al mismo tiempo,
ya que ambos protocolos tienen ID de contexto de servicio. Cuando el interceptor de solicitudes de clientes ha añadido el contexto de servicio
al mensaje, éste se envía al ORB del servidor.
El que un contexto de
servicio contenga una identidad exclusiva es otra de las razones por las
que WebSphere Application Server da soporte a z/SAS y CSIv2 al mismo tiempo,
ya que ambos protocolos tienen ID de contexto de servicio. Cuando el interceptor de solicitudes de clientes ha añadido el contexto de servicio
al mensaje, éste se envía al ORB del servidor.
Cuando el ORB del servidor recibe el mensaje, el ORB invoca el interceptor de solicitudes de servidores del protocolo de autenticación.
Este interceptor busca el ID de contexto de servicio que conoce el protocolo.
Cuando un servidor da soporte a SAS y CSIv2, se invocan dos interceptores
de solicitudes de servidores diferentes y ambos interceptores buscan
diferentes ID de contexto de servicio.
Cuando el ORB del servidor recibe el mensaje, el ORB invoca el interceptor de solicitudes de servidores del protocolo de autenticación.
Este interceptor busca el ID de contexto de servicio que conoce el protocolo.
Cuando un servidor da soporte a z/SAS y CSIv2, se invocan dos
interceptores de solicitudes de servidores diferentes y ambos interceptores
buscan diferentes ID de contexto de servicio.
Sin embargo, solamente uno de ellos encuentra un contexto de servicio para la solicitud especificada. Cuando el interceptor de solicitudes de servidores encuentra un contexto de servicio, lee la información del contexto de servicio. A continuación, se invoca un método para el servidor de seguridad autentique o valide la identidad del cliente. El servidor de seguridad rechaza la información o devuelve una credencial. Una credencial contiene información adicional acerca del cliente que se recupera del registro de usuarios de modo que la autorización pueda tomar la decisión correcta. La autorización es el proceso por el que se determina si el usuario puede invocar la solicitud basándose en los roles aplicados al método y en los roles concedidos al usuario.
Si el interceptor de solicitudes de servidores CSIv2 no encuentra un contexto de servicio, el procedo de interceptor buscará en la conexión de transporte para ver si se ha enviado una cadena de certificado de cliente. Este proceso se efectúa cuando se configura la autenticación del cliente SSL entre el cliente y el servidor.
Si se encuentra la cadena de certificado, se extrae
el nombre diferenciado (DN) del certificado y se utiliza para correlacionarlo con
una identidad del registro de usuarios. Si el registro de usuarios es LDAP (Lightweight Directory Access Protocol), los filtros de
búsqueda definidos en la configuración del registro LDAP determinan cómo se correlaciona el
certificado con una entrada en el registro. Si el registro de usuarios es Local OS,
el primer atributo del nombre distinguido (DN) se correlaciona con el ID de usuario
del registro. Este atributo es normalmente el nombre común.
Si el registro de usuarios es LDAP (Lightweight Directory Access Protocol), los filtros de
búsqueda definidos en la configuración del registro LDAP determinan cómo se correlaciona el
certificado con una entrada en el registro. Si el registro de usuarios es Local OS,
el certificado se correlaciona con un ID de usuario SAF (System Authorization
Facility). A continuación, puede correlacionar el ID de usuario, utilizando el
nombre de emisores o el nombre de sujetos, con el recurso de correlación de
certificados SAF.
Si el certificado no se correlaciona, no se crea ninguna credencial y se rechaza la solicitud. Si no se presenta información de seguridad válida, se rechaza la solicitud de método y se devuelve una excepción NO_PERMISSION con la respuesta. No obstante, si no se presenta información de seguridad, se crea una credencial no autenticada para la solicitud y el sistema de autorizaciones determina si se invoca el método. Si una credencial no autenticada invoca un método EJB (Enterprise JavaBeans), es porque no se han definido roles de seguridad para el método o porque se ha definido un rol especial Everyone para el método.
Cuando se ha invocado por completo el método en el contenedor de EJB, se vuelve a invocar el interceptor de solicitudes de servidores para que complete la autenticación de servidor y se crea un nuevo contexto de servicio en la respuesta para informar al interceptor de solicitudes de clientes del resultado. Generalmente, este proceso es para hacer que la solicitud sea con estado. Cuando se efectúa una solicitud con estado, solamente la primera solicitud entre un cliente y un servidor necesita que se envíe información de seguridad. Las solicitudes de método siguientes solamente necesitarán enviar un ID de contexto exclusivo para que el servidor busque la credencial almacenada en una tabla de sesión. El ID de contexto es exclusivo para la conexión entre un cliente y un servidor.
Finalmente, el ciclo de solicitud del método se completa cuando el interceptor de solicitudes de clientes recibe una respuesta del servidor con un contexto de servicio de respuesta que proporciona información para que pueda confirmarse y reutilizarse el ID de contexto con estado de cliente.
Un cliente con
estado se especifica mediante la propiedad com.ibm.CSI.performStateful (true/false). Un servidor con estado se especifica mediante la configuración de la consola
administrativa.
El cliente y el servidor dan
soporte a las sesiones con estado y sin estado, y esto no es configurable.

Política de autenticación para cada solicitud
La política de autenticación de una solicitud determinada que determina la protección de seguridad entre un cliente y un servidor. Una configuración de protocolo de autenticación de cliente o servidor puede describir las características necesarias, soportadas y no soportadas. Si un cliente requiere una característica, sólo puede comunicarse con servidores que requieran o que den soporte a esta característica. Si un servidor requiere una característica, sólo puede comunicarse con clientes que requieran o que den soporte a esta característica. Si un cliente da soporte a una característica, puede comunicarse con un servidor que dé soporte o requiera esa característica, pero también puede comunicarse con servidores que no den soporte a la característica. Si un servidor da soporte a una característica, puede comunicarse con un cliente que dé soporte o requiera esta característica, pero también puede comunicarse con clientes que no den soporte a la característica o que hayan optado por dar soporte a la característica.
Por ejemplo, si un cliente da soporte a la autenticación del cliente de soporte, será necesario algún procedimiento de configuración para generar un certificado autofirmado o para obtener un certificado de la autoridad certificadora (CA). Puede que algunos clientes no tengan que realizar todas estas acciones, por lo que puede configurar esta característica como no soportada. Al tomar esta decisión, el cliente no podrá comunicarse con un servidor seguro que requiera autenticación de certificados por parte del cliente. En su lugar, los clientes pueden optar por utilizar el ID de usuario y la contraseña como método de autenticación ante el servidor.
Generalmente, dar soporte a una característica es el método más común de configurar características. También es el que mejor se ejecuta ya que es más tolerante que requerir una característica. Con la información sobre cómo se configuran los servidores seguros en su dominio, puede seleccionar la combinación correcta para que el cliente pueda invocar correctamente los métodos y, al mismo tiempo, obtenga la mayor seguridad posible. Si sabe que todos los servidores dan soporte a los certificados de cliente y a la autenticación de ID de usuario y contraseña para el cliente, es posible que desee dar soporte a un método y no al otro. Si en el cliente y el servidor están soportados ambos métodos de ID de usuario y contraseña y de certificado de cliente, se ejecutarán ambos métodos pero el método de ID de usuario y contraseña tendrá prioridad en el servidor. Esta acción se basa en los requisitos de la especificación CSIv2.