Seguridad de conectores Java EE
La arquitectura de conectores Java™ 2 Platform, Enterprise Edition (Java EE) define una arquitectura estándar para conectar J2EE a sistemas de información empresarial (EIS) heterogéneos. Los ejemplos de EIS son ERP (Enterprise Resource Planning), los TP (procesos de transacciones) de hosts y los sistemas de base de datos.
La arquitectura del conector permite que un proveedor de EIS proporcione un adaptador de recursos estándar para su EIS. Un adaptador de recursos es un controlador de software de nivel de sistema que utiliza una aplicación Java para conectarse a un EIS. El adaptador de recursos se puede conectar al servidor de aplicaciones y proporciona conectividad entre el EIS, el servidor de aplicaciones y la aplicación de empresa. Para acceder a la información del EIS, normalmente se necesita un control de acceso que impida el acceso no autorizado. Las aplicaciones J2EE deben autenticarse en el EIS para abrir una conexión.
- BasicPassword: el mecanismo básico de autenticación basado en contraseñas de usuario específico de un EIS
Kerbv5: el mecanismo de autenticación basado en la versión 5 de Kerberos
Las aplicaciones definen si se debe utilizar el inicio de sesión gestionado por aplicación o el inicio de sesión gestionado por contenedor en los elementos resource-ref del descriptor de despliegue. Cada elemento resource-ref describe un único enlace de referencia de fábrica de conexiones. El elemento res-auth en un elemento resource-ref, cuyo valor puede ser Application o Container, indica si el código del enterprise bean puede realizar el inicio de sesión o si el servidor de aplicaciones puede realizar el inicio de sesión en el gestor de recursos utilizando la configuración de correlación de principales. El elemento resource-ref se define habitualmente en el momento de ensamblaje de aplicaciones con una herramienta de ensamblaje. resource-ref también se puede definir o redefinir en el momento del despliegue.
Inicio de sesión gestionado por aplicación
Para acceder a un sistema EIS, las aplicaciones localizan una fábrica de conexiones del espacio de nombres JNDI (Java Naming and Directory Interface) e invocan el método getConnection en ese objeto de fábrica de conexiones. El método getConnection puede necesitar un argumento de ID de usuario y contraseña. Una aplicación J2EE puede pasar un ID de usuario y una contraseña al método getConnection que, a su vez, pasa la información al adaptador de recursos. Especificar un ID de usuario y una contraseña en el código de aplicación puede poner en riesgo la seguridad.
El ID de usuario y la contraseña, si se codifican en el código de origen Java, están disponibles para los desarrolladores y los evaluadores de la organización. Asimismo, el ID de usuario y la contraseña están visibles para los usuarios si descompilan la clase Java.
El ID de usuario y la contraseña no se pueden modificar si no se cambia primero el código. Como alternativa, el código de aplicación puede recuperar conjuntos de ID de usuario y contraseñas a partir del almacenamiento persistente o de un servicio externo. Para utilizar este método, los administradores de TI deben configurar y gestionar un ID de usuario y una contraseña utilizando el mecanismo específico de la aplicación.
Para acceder a estos datos de autenticación, el servidor de aplicaciones da soporte a un alias de autenticación gestionada por componentes que debe especificarse en un recurso. Estos datos de autenticación son comunes para todas las referencias al recurso. Pulse
. Seleccione Utilizar alias de autenticación gestionado por el componente.- El ID de usuario y la contraseña que se pasan al método getConnection
- El alias de autenticación gestionada por componentes de la fábrica de conexiones o el origen de datos
- Las propiedades personalizadas de nombre de usuario y contraseña del origen de datos
Las propiedades de nombre de usuario y contraseña se pueden definir inicialmente en el archivo RAR (Resource Adapter Archive).
Estas propiedades también se pueden
definir en la consola administrativa o con scripts de wsadmin de las propiedades
personalizadas.
No utilice las propiedades personalizadas, que permiten a los usuarios
conectarse a los recursos.
Inicio de sesión gestionado por contenedor
El servidor de aplicaciones puede proporcionar el ID de usuario y la contraseña de los sistemas de información de empresa (EIS) de destino. El producto proporciona funcionalidad de inicio de sesión gestionado por contenedor. El servidor de aplicaciones localiza los datos de autenticación adecuados para el EIS de destino para que el cliente pueda establecer una conexión. El código de aplicación no tiene que proporcionar un ID de usuario y una contraseña en la llamada a getConnection cuando está configurado para utilizar el inicio de sesión gestionado por contenedor, ni los datos de autenticación tienen que ser comunes para todas las referencias a un recurso. Se utiliza un mecanismo de autenticación conectable de JAAS (Java Authentication and Authorization Service) para utilizar una configuración de inicio de sesión JAAS preconfigurado, y LoginModule para correlacionar una identidad de seguridad del cliente y credenciales en la hebra de ejecución con un ID de usuario y una contraseña preconfigurados.
El producto da soporte a un módulo LoginModule de correlación por omisión de credenciales de "varias con una" que correlaciona todas las identidades de cliente de la hebra de ejecución con un ID de usuario y una contraseña preconfigurados para un EIS de destino especificado. El módulo de correlación por omisión es un módulo LoginModule JAAS específico que devuelve una credencial PasswordCredential especificada por la entrada de datos de autenticación J2C (Java 2 Connector) configurada. El módulo LoginModule de correlación por omisión realiza una búsqueda en la tabla, pero no realiza la autenticación. El ID de usuario y la contraseña se almacenan juntos con un alias en la lista de datos de autenticación J2C.
La lista de datos de autenticación J2C se encuentra en el panel Seguridad global en Java Authentication and
. La función de correlación predeterminada de principales y credenciales se define mediante la configuración de inicio de sesión JAAS de la aplicación DefaultPrincipalMapping.Los datos de autenticación J2C que se modifican utilizando la consola de administración entran en vigor cuando se guarda la modificación en el repositorio y se ejecuta Conexión de prueba. Asimismo, los datos de autenticación de J2C que se modifican utilizando scripts de wsadmin se aplican cuando se inicia o se reinicia una aplicación para un determinado proceso de servidor de aplicaciones. La modificación de datos de autenticación de J2C entra en vigor al invocar el método de MBean SecurityAdmin, updateAuthDataCfg. Establezca el parámetro HashMap como null para habilitar el MBean Securityadmin para renovar los datos de autenticación J2C utilizando los valores más recientes del repositorio.
No modifique la configuración de inicio de sesión de DefaultPrincipalMapping, ya que el producto incluye mejoras de rendimiento a esta configuración de correlación predeterminada que se utiliza con frecuencia. El producto no admite la modificación de la configuración de DefaultPrincipalMapping, cambiar el módulo LoginModule predeterminado ni apilar un módulo LoginModule personalizado en la configuración.
En la plataforma z/OS, si no existen un ID de usuario y una
contraseña, ni se obtienen por omisión de un alias, el tiempo de ejecución
de WebSphere Application Server busca un ID de usuario SAF (System
Authorization Facility) en el sujeto.
Para la mayoría de sistemas, el método predeterminado de una correlación de "varias con una" es suficiente. No obstante, el producto admite las configuraciones de correlación personalizada de principales y credenciales. Los módulos de correlación personalizada se pueden añadir a la configuración JAAS de inicios de sesión de la aplicación creando una nueva configuración de inicio de sesión JAAS con un nombre exclusivo. Por ejemplo, un módulo de correlación personalizada puede proporcionar una correlación de "uno a uno" o la funcionalidad de Kerberos.
Además, las conexiones de confianza proporcionan una correlación de "uno a uno" al tiempo que dan soporte a la propagación de identidad de cliente. Además de utilizar el objeto de contexto de confianza DB2, las conexiones de confianza pueden aprovechar la agrupación de conexiones para reducir la penalización de rendimiento de cerrar y reabrir conexiones con una identidad diferente. El uso de conexiones de confianza también amplía la seguridad de la base de datos DB2 al eliminar la necesidad de asignar todos los privilegios a un solo usuario. Un usuario cuyas credenciales son de confianza para el servidor DB2 para abrir la conexión es el que establece la conexión, y a ese mismo usuario se le da confianza para confirmar la identidad de los demás usuarios que acceden al servidor DB2 desde la aplicación. Una nueva configuración de la correlación denominada TrustedConnectionMapping se ha creado para implementar conexiones de confianza.
También puede utilizar la consola administrativa de WebSphere Application Server para enlazar las referencias de la fábrica de conexiones del gestor de recursos con una de las fábricas de recursos configuradas. Si el valor del elemento res-auth es Container dentro del descriptor de despliegue de la aplicación, debe especificar la configuración de correlación. Para especificar la configuración de correlación, utilice el enlace Referencias de recursos bajo Referencias en el panel . Consulte el tema Correlación de referencias de recursos con referencias para obtener instrucciones adicionales.
Módulos de correlación de J2C y propiedades de correlación
Los módulos de correlación son módulos de inicio de sesión JAAS especiales que proporcionan funciones de correlación de principales y credenciales. Puede definir y configurar módulos de correlación personalizada mediante la consola administrativa.
También puede definir y pasar datos de contexto a los módulos de correlación utilizando las opciones de inicio de sesión de cada configuración de inicio de sesión JAAS. En el producto, también puede definir datos de contexto utilizando propiedades de correlación en cada enlace de referencia de fábrica de conexiones.
Las opciones de inicio de sesión que se definen en cada configuración de inicio de sesión JAAS se comparten entre todos los recursos que utilizan los mismos módulos de correlación y la misma configuración de inicio de sesión JAAS. Las propiedades de correlación que se definen para cada enlace de referencia de fábrica de conexiones se utilizan exclusivamente en esa referencia de recurso.
Considere un ejemplo de uso donde se utilice un servicio de correlación externa.
Por ejemplo, puede utilizar el servicio GSO (Global Sign-On) de Tivoli Access Manager. Utilice el GSO de Tivoli Access Manager para localizar los datos de autenticación de ambos servidores de programa de fondo.
Tiene dos servidores EIS: DB2 y MQ. No obstante, los datos de autenticación de DB2 son distintos de los de MQ. Utilice la opción de inicio de sesión en una configuración de inicio de sesión JAAS de correlación para especificar los parámetros que se necesitan para establecer una conexión con el servicio GSO de Tivoli Access Manager. Utilice las propiedades de correlación en un enlace de referencia de fábrica de conexiones para especificar qué servidor EIS requiere el ID de usuario y la contraseña.
Para obtener información más detallada sobre cómo desarrollar un módulo de correlación, consulte el tema sobre módulos de correlación de principales J2C.
- La configuración de correlación en la fábrica de conexiones ha pasado a la referencia de fábrica de conexiones del gestor de recursos. Los módulos de inicio de sesión de correlación que se desarrollan utilizando los tipos de retorno de llamada JAAS de WebSphere Application Server Versión 5 se pueden utilizar en la referencia de fábrica de conexiones del gestor de recursos, pero los módulos de inicio de sesión de correlación no pueden aprovechar la característica de propiedades de correlación personalizadas.
- El enlace de referencia de fábrica de conexiones da soporte a las propiedades de correlación, y las pasa a los módulos de inicio de sesión de correlación mediante un nuevo retorno de llamada WSMappingPropertiesCallback. Asimismo, el retorno de llamada WSMappingPropertiesCallback y el nuevo retorno de llamada WSManagedConnectionFactoryCallback se definen en el paquete com.ibm.wsspi. Utilice los nuevos módulos de inicio de sesión de correlación con los nuevos tipos de retorno de llamada.
Entrega de mensajes seguros con SecurityContext de entrada
Un adaptador de recursos EIS puede proporcionar información de seguridad al servidor de aplicaciones mediante el contexto de flujo de entrada de seguridad. El mecanismo de contexto de flujo de entrada de seguridad permite que el gestor de trabajo ejecute las acciones de una instancia de trabajo en una identidad establecida. Esas acciones incluyen la entrega de mensajes a los puntos finales de mensajes Java EE que se procesan como beans controlados por mensajes (MDB) bajo una identidad que está configurada en un dominio de seguridad del servidor de aplicaciones.
La entrega segura de mensajes a un punto final de mensaje requiere que la seguridad global esté habilitada en la configuración de la seguridad global. También requiere que está habilitada la seguridad de aplicaciones en el servidor de aplicaciones que aloja la aplicación que proporciona el MDB de punto final del mensaje. Si desea más información sobre la seguridad global, consulte el tema, "Valores de seguridad global".
La política de seguridad del descriptor de despliegue de la aplicación debe configurarse con roles que estén asociados a las identidades de usuario del reino de la aplicación, que es el registro de usuarios del dominio de seguridad con ámbito de la aplicación. Esta configuración de seguridad habilita la seguridad EJB y autoriza a identidades de usuario específicas del reino de la aplicación acceder a métodos de MDB. Si desea más información sobre la visión general de seguridad, consulte el tema, "Seguridad".
La entrega de mensajes seguros también requiere que el adaptador de recursos defina implementaciones tanto para la interfaz WorkContextProvider como para la interfaz SecurityContext. Para entregar un mensaje seguro, un adaptador de recursos primero somete una instancia de trabajo que proporciona una implementación SecurityContext, que el gestor de trabajo utiliza para establecer el asunto de ejecución para esa instancia de trabajo.
Al establecer el asunto de ejecución, un SecurityContext puede proporcionar las implementaciones de devoluciones de llamada de JASPIC (Java Authentication Service Provider Interface for Containers) que el gestor de trabajo utiliza para determinar las identidades de emisor de llamada y grupo (CallerPrincipalCallback, GroupPrincipalCallback) y autenticar la identidad del emisor de llamada y la contraseña (PasswordValidationCallback). Si la identidad de llamante se encuentra en el reino de la aplicación, el gestor de trabajo afirma esa identidad construyendo una instancia WSSubject que contiene el principal de llamante, los principales de grupo y todas las credenciales privadas.
Como alternativa, SecurityContext puede proporcionar un asunto de ejecución que es una instancia de WSSubject instancia creada por otro módulo de inicio de sesión o autenticación. El gestor de trabajo acepta esta instancia de WSSubject sólo cuando su principal de llamante sea WSSubject en el reino de la aplicación o en un ámbito de confianza. Si desea más información sobre reinos, consulte el tema, "Configuración de reinos de confianza de entrada para varios dominios de seguridad".
El gestor de trabajo rechaza una instancia de trabajo siempre que no puede establecer una instancia de WSSubject. De lo contrario, se asigna la instancia en una hebra gestionada bajo la instancia WSSubject que se ha confirmado o aceptado. Si SecurityContext no proporciona la identidad de llamante, la instancia de trabajo asigna bajo una instancia de WSSubject que contiene el principal de llamante autenticado.
Cuando se asigna, una instancia de trabajo puede intentar entregar mensajes al MDB de la aplicación protegida. Todos los mensajes se entregan bajo la instancia WSSubject establecida para la instancia de trabajo. El colaborador de seguridad EJB proporciona acceso al método onMessage del MDB siempre que el principal del llamante de la instancia WSSubject está asociado con un rol que se declara en el descriptor de despliegue de aplicaciones. De lo contrario, el colaborador deniega el acceso y el mensaje no se entrega. Durante la entrega, el MDB puede utilizar los métodos de contexto EJB, isCallerInRole y getCallerPrincipal, para tomar decisiones de acceso adicionales, y es posible que el MDB acceda a otras entidades en el dominio de seguridad para las que el principal del llamante tenga autorización.