Soporte de JACC en WebSphere Application Server
WebSphere Application Server da soporte a la especificación JACC (Java™ Authorization Contract for Containers), que permite a los proveedores de seguridad de terceros manejar la autorización de Java Platform, Enterprise Edition (Java EE).
La especificación JACC requiere que los contenedores del servidor de aplicaciones y del proveedor cumplan determinados requisitos. En concreto, los contenedores deben propagar la información de políticas de seguridad al proveedor durante el despliegue de la aplicación y llamar al proveedor para todas las decisiones de autorización. Los proveedores deben almacenar la información de políticas en su repositorio durante el despliegue de la aplicación. Posteriormente, los proveedores pueden utilizar esta información para tomar decisiones de autorización cuando los llama el contenedor.
Decisiones de acceso de JACC
Cuando la seguridad está habilitada y se accede a un enterprise bean o un recurso web, el contenedor de EJB (Enterprise JavaBeans) o el contenedor web llama al tiempo de ejecución de seguridad para tomar una decisión de autorización sobre si debe permitir o no el acceso. Cuando se utiliza un proveedor externo, la decisión de acceso se delega a ese proveedor.
Según la especificación JACC (Java Authorization Contract for Containers), se crea el objeto de permiso correspondiente, se registran los manejadores de contexto de política adecuados y se establece el identificador de contexto (contextID) de política correcto. Se realiza una llamada al método del objeto java.security.Policy implementado por el proveedor para tomar la decisión de acceso.
En los apartados siguientes se describe cómo se llama al proveedor para el enterprise bean y los recursos web.
Decisiones de acceso para enterprise beans
- Crea el objeto EJBMethodPermission utilizando el nombre del bean, el nombre del método, el nombre de la interfaz y la signatura del método.
- Crea el ID de contexto y lo establece en la hebra utilizando el método PolicyContext.setContextID(contextID).
- Registra los manejadores de contexto de políticas necesarios, incluido el manejador de contexto de políticas de sujeto.
- Crea el objeto ProtectionDomain con el principal en el sujeto. Si no existe ningún principal, se pasa null como nombre del principal.
- La decisión de acceso se delega al proveedor de JACC llamando al método implies del objeto Policy, que implementa el proveedor. Los objetos EJBMethodPermission y ProtectionDomain se pasan a este método.
- La comprobación de acceso isCallerInRole también sigue el mismo proceso, excepto que se crea un objeto EJBRoleRefPermission en lugar de un objeto EJBMethodPermission.
Decisiones de acceso para recursos web
- Se crea un objeto WebResourcePermission para ver si se ha
deseleccionado el URI. Si el proveedor reconoce el sujeto Everyone, también se debe
seleccionar aquí.
- Se construye el objeto WebResourcePermission con el urlPattern y el método HTTP al que se ha accedido.
- Se crea un objeto ProtectionDomain con un nombre de principal nulo.
- Se llama al método Policy.implies del proveedor de JACC con el permiso y el dominio de protección. Si se ha borrado el acceso al URI o se ha proporcionado acceso al sujeto Everyone, el proveedor permite el acceso (devolver true) en el método implies. A continuación, se otorga el acceso sin más comprobaciones.
- Si no se ha otorgado el acceso en el paso anterior, se crea un objeto
WebUserDataPermission y se utiliza para ver si el URI (Uniform Resource
Identifier) está excluido o se debe redireccionar utilizando el protocolo
HTTPS.
- El objeto WebUserDataPermission se construye con el urlPattern al que se ha accedido, el método HTTP invocado y el tipo de transporte de la solicitud. Si la solicitud se realiza a través de HTTPS, el tipo de transporte se establece como CONFIDENTIAL; de lo contrario, se pasa null.
- Se crea un objeto ProtectionDomain con un nombre de principal nulo.
- Se llama al método Policy.implies del proveedor de JACC con el permiso y el dominio de protección. Si la petición utiliza el protocolo HTTPS y el método implies devuelve false, se devuelve el error HTTP 403 para implicar un permiso excluido. En este caso, no se realizan más comprobaciones. Si la petición no utiliza el protocolo HTTPS y el método implies devuelve false, la petición se redirige a través de HTTPS.
- El tiempo de ejecución de seguridad intenta autenticar el usuario. Si la información de autenticación ya existe (por ejemplo, la señal LTPA), se utiliza. De lo contrario, se deben entrar las credenciales del usuario.
- Una vez validadas las credenciales del usuario, se realiza una
comprobación de autorización final para ver si se han otorgado al usuario
privilegios de acceso al URI.
- Se crea el objeto WebResourcePermission, de la misma forma que en el paso 1. El objeto ProtectionDomain contiene ahora el principal que intenta acceder al URI. El manejador de contexto de políticas de sujeto también contiene la información del usuario, que se puede utilizar para la comprobación de acceso.
- Se llama al método implies del proveedor utilizando el objeto Permission y el objeto ProtectionDomain creados anteriormente. Si se otorga permiso al usuario para acceder al recurso, el método implies devuelve true. Si no se otorga acceso al usuario, el método implies devuelve false.
Para obtener más información sobre estos permisos de acceso, consulte JSR-000115 Java Authorization Contract for Containers (release de mantenimiento de la versión 1.5).
Utilización de la información del sujeto para la decisión de acceso
Si el proveedor se basa en el sujeto generado por WebSphere Application Server para la decisión de acceso, el proveedor puede consultar las credenciales públicas en el sujeto para obtener la credencial WSCredential. Se utiliza la API de WSCredential para obtener información sobre el usuario, incluido el nombre y los grupos a los que pertenece el usuario. Esta información se utiliza para tomar la decisión de acceso.
Si el proveedor añade la información necesaria al sujeto, WebSphere Application Server puede utilizar la información para tomar decisiones de acceso. El proveedor puede añadir la información utilizando la característica de Interfaz de asociación de confianza o conectando módulos de inicio de sesión al servidor de aplicaciones.
La sección de propagación de atributos de seguridad incluye documentación adicional sobre cómo añadir la información necesaria de WebSphere Application Server al sujeto. Para obtener más información, consulte Propagación de atributos de seguridad entre servidores de aplicaciones.
Actualizaciones de módulos dinámicos en JACC
WebSphere Application Server da soporte a actualizaciones dinámicas de módulos web en determinadas condiciones. Si un módulo Web se actualiza, se suprime o se añade a una aplicación, sólo se detiene y se inicia ese módulo, según corresponda. Los demás módulos existentes en la aplicación no se verán afectados, y la aplicación tampoco se detiene y se reinicia.
Cuando se utiliza el motor de autorizaciones por omisión, se modifican las políticas de seguridad en los módulos web, y la aplicación se detiene y se reinicia. Cuando se utiliza la autorización basada en JACC (Java Authorization Contract for Containers), el comportamiento depende de la funcionalidad que proporciona el proveedor. Si el proveedor puede manejar cambios dinámicos en los módulos web, sólo se ven afectados los módulos web. De lo contrario, se detiene y se reinicia la aplicación completa para aplicar los nuevos cambios en los módulos web.
Un proveedor puede indicar si da soporte a las actualizaciones dinámicas configurando la opción Soporta actualizaciones dinámicas de módulos en el modelo de configuración JACC (consulte Autorización de acceso a los recursos Java EE utilizando Tivoli Access Manager para obtener más información). Esta opción se puede habilitar o inhabilitar mediante la consola administrativa o utilizando scripts. Normalmente, la mayoría de proveedores almacena la información de políticas en el repositorio externo, lo que les permite dar soporte a estas actualizaciones dinámicas. Esta opción debe estar habilitada por omisión para la mayoría de proveedores.
Cuando está habilitada la opción Soporta actualizaciones dinámicas de módulos, si se añade, se modifica o se suprime de forma dinámica un módulo web que contiene roles de seguridad, sólo se modificarán y se reiniciarán los módulos web específicos. Si la opción está inhabilitada, se reiniciará la aplicación completa. Cuando se realizan actualizaciones dinámicas, la información de políticas de seguridad de los módulos afectados se propaga al proveedor. Para obtener más información sobre la propagación de políticas de seguridad, consulte Propagación de políticas JACC.
Inicialización del proveedor de JACC
Si un proveedor de JACC (Java Authorization Contract for Containers) se debe inicializar durante el arranque del servidor, por ejemplo, para habilitar la comunicación entre el código de cliente y el código de servidor, puede implementar la interfaz com.ibm.wsspi.security.authorization.InitializeJACCProvider. Para obtener más información, consulte el apartado Interfaces que dan soporte a JACC.
Cuando se implementa esta interfaz, se invoca durante el arranque del servidor. Las propiedades personalizadas en el modelo de configuración JACC se propagan al método initialize de esta implementación. Las propiedades personalizadas se pueden entrar mediante la consola administrativa o utilizando scripts.
Durante el cierre del servidor, se llama al método cleanup para los trabajos de limpieza que necesite el proveedor. La implementación de esta interfaz es estrictamente opcional y sólo se utiliza si el proveedor se debe inicializar durante el arranque del servidor.
Entorno combinado de nodos y JACC
La autorización con JACC (Java Authorization Contract for Containers) era una nueva característica en WebSphere Application Server Versión 6 y se ha mejorado a la última versión 1.5 de la especificación JACC en WebSphere Application Server Versión 9.
La configuración JACC se configura a nivel de célula y se aplica a todos los nodos y servidores de esa célula.
Si tiene previsto utilizar las funciones de la versión 5.1 de la autorización basada en JACC, la célula sólo puede contener nodos de la versión 9 y posteriores. Esta restricción significa que un entorno combinado de nodos que contenga nodos de la versión 8.5.x o anteriores en una célula de la versión 9 o posteriores está soportado para la autorización basada en JACC que utilice la versión mínima soportada en la célula. En este caso, es la versión 1.4 de la autorización basada en JACC.