Varios dominios de seguridad

Los dominios de seguridad de WebSphere proporcionan la flexibilidad para utilizar diferentes configuraciones de seguridad en WebSphere Application Server. El dominio de seguridad de WebSphere (WSD) también se conoce como varios dominios de seguridad o, simplemente, como dominios de seguridad. Puede configurar diferentes atributos de seguridad, como por ejemplo UserRegistry, para diferentes aplicaciones.

Nota: El soporte de varios dominios de seguridad se introdujo en WebSphere Application Server Versión 7.0. Puede crear diferentes configuraciones de seguridad y asignarlas a distintas aplicaciones en los procesos de WebSphere Application Server. Mediante la creación de varios dominios de seguridad, puede configurar distintos atributos de seguridad para aplicaciones administrativas y de usuario en un entorno de célula. Puede configurar diferentes aplicaciones para utilizar diferentes configuraciones de seguridad mediante las asignaciones de servidores, clústeres o buses de integración de servicios que contengan estas aplicaciones a los dominios de seguridad. Sólo podrán configurar varios dominios de seguridad los usuarios a los que se les haya asignado el rol de administrador.

Razones de la utilidad de los dominios de seguridad

Los dominios de seguridad de WebSphere proporcionan dos beneficios principales:

  • Las aplicaciones administrativas de WebSphere Application Server pueden configurarse con un conjunto diferente de configuraciones de seguridad de las utilizadas para aplicaciones de usuario.
  • Habilitan un conjunto de aplicaciones para tener un conjunto de configuraciones diferentes de otro conjunto de aplicaciones.

    [z/OS]Por ejemplo, la administración de WebSphere Application Server puede configurarse para un registro de usuarios de RACF mientras que las aplicaciones pueden configurarse para un registro de usuarios de LDAP.

    [AIX Solaris HP-UX Linux Windows][IBM i]Por ejemplo, la administración de WebSphere Application Server puede configurarse para un registro de usuarios del repositorio federado mientras que las aplicaciones pueden configurarse para un registro de usuarios de LDAP.

En versiones anteriores de WebSphere Application Server, todas las aplicaciones administrativas y de usuario comparten la mayor parte de los atributos de seguridad. Todas las aplicaciones administrativas y de usuario de WebSphere Application Server utilizan atributos de seguridad global predeterminados. Por ejemplo, un registro de usuarios definido en la seguridad global se utiliza para autenticar un usuario de cada una de las aplicaciones de la célula.

En este release de WebSphere Application Server, sin embargo, puede utilizar varios atributos de seguridad para aplicaciones de usuario que no sean los atributos de seguridad global, crear un dominio de seguridad para los atributos de seguridad que deben ser diferentes y asociarlos con los servidores y clústeres que contienen aplicaciones de usuario. También puede asociar un dominio de seguridad con la célula. Todas las aplicaciones de usuario de la célula utilizan este dominio de seguridad si no se les ha asociado ningún dominio anteriormente. Sin embargo, los atributos de seguridad global siguen siendo necesarios para las aplicaciones administrativas, como por ejemplo la consola administrativa, los recursos de denominación y los MBeans.

Si ha utilizado seguridad de nivel de servidor en los releases anteriores de WebSphere Application Server, ahora deberá utilizar varios dominios de seguridad, ya que son más flexibles y fáciles de configurar.

La seguridad de nivel de servidor está en desuso en este release. Consulte Relación entre la seguridad global y los dominios de seguridad si desea más información.

Relación entre la seguridad global y los dominios de seguridad

La seguridad global se aplica a todas las funciones administrativas y la configuración de seguridad por omisión de las aplicaciones de usuario. Los dominios de seguridad pueden utilizarse para definir una configuración personalizada para aplicaciones de usuario.

Debe haber definido una configuración de seguridad global para poder crear dominios de seguridad. Las aplicaciones administrativas, como por ejemplo la consola administrativa, los recursos de denominación y los Mbeans utilizan la configuración de seguridad global. Si no se configura ningún dominio de seguridad, todas las aplicaciones utilizarán la información de la configuración de seguridad global. Las aplicaciones de usuario, como por ejemplo Enterprise JavaBeans (EJBs), servlets y aplicaciones administrativas utilizan la misma configuración de seguridad.

Al crear un dominio de seguridad y asociarlo con un ámbito, sólo las aplicaciones de usuario de dicho ámbito utilizarán los atributos de seguridad definidos en el dominio de seguridad. Las aplicaciones administrativas, así como las operaciones de denominación de dicho ámbito, utilizan la configuración de seguridad global. Defina los atributos de seguridad a nivel de dominio que deben ser diferentes respecto a los del nivel global. Si ambos tipos de atributos comparten la misma información, no es necesario que la información esté duplicada en el dominio de seguridad. Todos los atributos que falten en el dominio se obtienen de la configuración global. Los datos de configuración de seguridad global se almacenan en el archivo security.xml, el cual se encuentra en el directorio $WAS_HOME/profiles/$ProfileName/cells/$CellName.

En la figura siguiente, se proporciona un ejemplo de varios dominios de seguridad donde la célula, un servidor y un clúster están asociados con diferentes dominios de seguridad. Como se muestra en la figura, las aplicaciones de usuario del servidor S1.1, así como el clúster, utilizan atributos de seguridad definidos en Domain2 y Domain3 respectivamente (puesto que estos ámbitos están asociados con estos dominios). El servidor S2.2 no está asociado con un dominio. Como resultado, la aplicación de usuario de S2.2 utiliza el dominio asociado con la célula (Domain1) predeterminada. Los atributos de seguridad que faltan a nivel de dominio se obtienen de la configuración global.

Figura 1. Ámbitos que pueden asociarse con un dominio de seguridadEjemplo de dominio múltiple de seguridad donde la célula, un servidor y un clúster están asociados con diferentes dominios de seguridad. Como se muestra en la figura, las aplicaciones de usuario del servidor S1.1 así como el clúster utilizan atributos de seguridad definidos en el Dominio2 y Dominio3 respectivamente (puesto que estos ámbitos están asociados con estos dominios). El servidor S2.2 no está asociado con un dominio. Por consiguiente, la aplicación de usuario de S2.2 utiliza de manera predeterminada el dominio que está asociado con la célula (Dominio1). Los atributos de seguridad que faltan en el nivel de dominio se obtienen de la configuración global.

En la figura siguiente, se muestran los diferentes atributos de seguridad de nivel elevado que se pueden definir en la configuración de seguridad global y los que se pueden sobrescribir a nivel de dominio.

Figura 2. Atributos de seguridad que pueden configurarse en el dominio de seguridadVarios atributos de seguridad de alto nivel que se pueden definir en la configuración de seguridad global y los que se pueden alterar temporalmente a nivel de dominio.

Contenido de un dominio de seguridad

Un dominio de seguridad se representa mediante dos archivos de configuración. Un archivo de configuración contiene la lista de atributos que se configuran en el dominio de seguridad. El otro archivo de configuración contiene los ámbitos que utiliza el dominio de seguridad. La información del dominio de seguridad se almacena en el directorio $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName. Para cada dominio de seguridad que se configure, se crea un directorio $SecurityDomainName que contendrá dos ficheros: el archivo security-domain.xml contiene la lista de atributos de seguridad configurados para el dominio de seguridad y el archivo security-domain-map.xml contiene los ámbitos que utilizan el dominio de seguridad.

En la figura siguiente, se indica la ubicación de los archivos relacionados con el dominio de seguridad principal, así como el contenido de dichos archivos.

Figura 3. Ubicación y contenido de los archivos relacionados con el dominio de seguridad principalUbicación de los principales archivos relacionados con el dominio de seguridad y contenido de esos archivos.
Nota: Estos archivos no pueden modificarse de forma manual. En su lugar, utilice las tareas de la consola administrativa o los mandatos de scripts para modificar los archivos. Para obtener una lista completa de las tareas administrativas y los mandatos de scripts, consulte los enlaces de "Tareas relacionadas" al final de este documento.

Creación de dominios de seguridad

Utilice las tareas de la consola administrativa o los mandatos de scripts para crear dominios de seguridad. En la consola administrativa, acceda a los dominios de seguridad pulsando Seguridad > Dominios de seguridad. Puede acceder a la Ayuda desde cada panel de la consola administrativa.

Para obtener una lista completa de las tareas de la consola de administración y los mandatos de scripts, consulte los enlaces de "Tareas relacionadas" al final de este documento.

Al crear un dominio de seguridad, deberá proporcionar un nombre exclusivo para el dominio, los atributos de seguridad que desea configurar para el dominio de seguridad y los ámbitos que deben utilizar el dominio de seguridad. Una vez configurados, deberá reiniciar el dominio de seguridad. Las aplicaciones de usuario de dichos ámbitos utilizarán los atributos definidos en el dominio de seguridad. Todos los atributos no configurados a nivel de dominio se obtendrán de la configuración de seguridad global. Las aplicaciones administrativas y las operaciones de denominación de los ámbitos siempre utilizan atributos de seguridad de la configuración de seguridad global. Debe gestionar estos atributos de forma activa.

Todos los atributos de dominio nuevos deben ser compatibles con los atributos de seguridad global heredados por las aplicaciones de usuario asignadas al dominio.

Excepto en el caso de las propiedades personalizadas y de JAAS, una vez que los atributos globales se han personalizado para un dominio, dejan de ser utilizados por las aplicaciones de usuario.

El panel de dominios de seguridad de la consola administrativa permite asignar recursos y seleccionar los atributos de seguridad adecuados para el dominio. El panel muestra los atributos de seguridad clave en la configuración global. Puede tomar la decisión de sobrescribirlos a nivel de dominio en caso necesario. Una vez que haya configurado y guardado los atributos a nivel de dominio, el valor del resumen del panel mostrará el valor personalizado del dominio (marcado con la palabra "personalizado" de color negro).

Un ámbito (un servidor, un clúster, un bus de integración de servicio o una célula) sólo se puede asociar con un dominio. Por ejemplo, no se pueden definir dos dominios que tengan un ámbito a nivel de célula. Si embargo, es posible definir varios ámbitos en el mismo dominio de seguridad. Por ejemplo, se puede incluir un dominio en un ámbito para Server1 y Server2 sólo en la célula.

La sección de ámbitos asignada en el panel del dominio de seguridad muestra dos vistas: una que permite seleccionar y asignar ámbitos al dominio y otro vista que permite ver una lista de los ámbitos asignados actualmente. Para su comodidad, puede copiar todos los atributos de seguridad de un dominio existente o de la configuración global en un nuevo dominio de seguridad y, a continuación, modificar sólo los atributos que deben ser diferentes. Todavía deberá seguir asociando los ámbitos con los dominios copiados en cuestión.

Los mandatos de scripts también permiten crear, copiar y modificar dominios de seguridad. Una vez que haya creado un dominio, deberá ejecutar los mandatos adecuados para asociar los atributos de seguridad y ámbitos a éste.

Configuración de atributos para dominios de seguridad

Los atributos de seguridad que pueden configurarse a nivel de dominio en WebSphere Application Server Versión 9.0 son:

  • Seguridad de las aplicaciones
  • Seguridad Java™ 2
  • Reino de usuario (registro)
  • Asociación de confianza
  • Autenticación Web de SPNEGO (Simple and Protected GSS-API Negotiation)
  • Seguridad RMI/IIOP (CSIv2)
  • Inicios de sesión de JAAS (datos de aplicación, sistema y autenticación J2C)
  • Java Authentication SPI
  • Atributos de mecanismo de autenticación
  • Proveedor de autorización
  • Depósitos federados
  • [z/OS]Propiedades de z/OS
  • Propiedades personalizadas

Los paneles de dominios de seguridad de la consola administrativa muestran todos estos atributos de seguridad.

Algunos de los demás atributos conocidos que no se pueden alterar a nivel de dominio son los atributos Kerberos, de auditoría, de inicio de sesión único Web (SSO), Tivoli Access Manager (TAM). El atributo SSL (Secure Socket Layer) ya da soporte a diferentes atributos, pero no forma parte de la configuración del dominio. En el caso de todos los atributos a los que no se les da soporte a nivel de dominio, las aplicaciones de usuario del dominio comparten la configuración del nivel global.

Todos los atributos de dominio nuevos deben ser compatibles con los atributos de seguridad global heredados por las aplicaciones de usuario asignadas al dominio. Debe gestionar estos atributos de forma activa. Por ejemplo, si personaliza sólo una configuración JAAS a nivel de dominio, debe asegurarse de que funcione con el registro de usuario configurado a nivel global (si el registro de usuarios no está personalizado a nivel de dominio).

Excepto en el caso de las propiedades personalizadas y de JAAS, una vez que los atributos globales se han personalizado para un dominio, dejan de ser utilizados por las aplicaciones de usuario.

El tiempo de ejecución de cliente de Tivoli Access Manager se utiliza para proporciona autenticación (que utiliza TrustAssociationInterceptor y PDLoginModule) y autorización (que utiliza JACC) estableciendo contacto con los servidores TAM. Sólo hay un tiempo de ejecución de Tivoli Access Manager que compartan todos los servidores de una célula. Consulte el tema Configuración del proveedor de JACC de Tivoli Access Manager para obtener más información.

No se puede tener una configuración de Tivoli Access Manager diferente a nivel de dominio de seguridad para sobrescribir la configuración a nivel de célula. Sin embargo, hasta cierto punto, se puede especificar una configuración de TAI (Trust Association Interceptor) y JACC a nivel de dominio de seguridad. Por ejemplo, puede utilizar un interceptor de TAI o un proveedor de autorización diferente. Dado que la conectividad de servidor TAM sólo se puede definir a nivel global, puede tener diversos TAI definidos y configurados a nivel de dominio de seguridad. Algunos de estos TAI puede que no utilicen el repositorio TAM, mientras que otros sí lo hagan. Los TAI que no necesiten conectarse al TAM también se conectarán al servidor TAM definido a nivel global. De forma similar, mediante autorización, puede tener diversos proveedores de autorización externos configurados a nivel de dominio. Sin embargo, si alguno de estos proveedores externos requiere una conexión a TAM acaban por hablar con el servidor TAM configurado a nivel global.

Asociación de ámbitos con dominios de seguridad

En WebSphere Application Server Versión 9.0, puede asociar un dominio de seguridad a nivel de célula, el nivel de servidor, el nivel de clúster y el nivel de bus de integración de servicio.
Nota: Para obtener más información sobre el bus de integración de servicios y la seguridad de bus en múltiples dominios de seguridad de WebSphere Application Server Versión 9.0, consulte Seguridad de mensajería en caso de múltiples dominios de seguridad.

Cuando se asocia un dominio de seguridad con un servidor que no forma parte de un clúster, todas las aplicaciones de usuario de dicho servidor utilizarán los atributos del dominio de seguridad. Todos los atributos de seguridad que falten se obtienen de la configuración de seguridad global. Si el servidor forma parte de un clúster, podrá asociar el dominio de seguridad con el clúster pero no con los miembros individuales de dicho clúster. El comportamiento de seguridad será, en consecuencia, coherente en todos los miembros del clúster.

Si un servidor debe formar parte de un clúster, cree primero un clúster y asóciele el dominio de seguridad. Es posible que haya asociado un dominio con un servidor antes de que fuera miembro de un clúster. En tal caso, aunque el dominio se asocie con el servidor de forma directa, el código del tiempo de ejecución de seguridad no buscará en el dominio. Cuando un servidor es miembro de un clúster, el tiempo de ejecución de seguridad no tiene en cuenta los dominios de seguridad asociados directamente al servidor. Elimine el ámbito del servidor del dominio de seguridad y asóciele, en su lugar, el ámbito del clúster.

Un dominio de seguridad también puede asociarse a la célula. Esto suele realizarse cuando se desea asociar todas las aplicaciones de usuario de WebSphere Application Server con un dominio de seguridad. En este escenario, todas las aplicaciones administrativas y operaciones de denominación utilizan la configuración de seguridad global, mientras que todas las aplicaciones de usuario utilizan la configuración de nivel de dominio. Si desea dividir la información de la configuración de seguridad para aplicaciones administrativas y de usuario, esto es todo lo que necesita.

Si dispone de un entorno de varias versiones o tiene la intención de tener uno en el futuro y desea asociar dominios de seguridad a nivel de célula, lea Dominios de seguridad en un entorno de versiones mixtas para obtener más información al respecto.

Si se encuentra en un servidor de perfiles base para el que se ha definido un dominio de seguridad que, posteriormente, se federa en un gestor de despliegue, asocie el ámbito del servidor con el dominio de seguridad y no el ámbito de célula. Al federara dicho nodo, la información del dominio de seguridad se propaga al gestor de despliegue. Si se le asocia el ámbito de célula, la configuración de despliegue de red utilizará esta configuración de seguridad, lo cual puede tener un impacto en las aplicaciones existentes. Durante la federación, el ámbito de la célula cambia al ámbito del servidor que se está federando. Si el ámbito de servidor se asocia con el dominio de seguridad, sólo dicho servidor utilizará el dominio de seguridad después de la federación. Esto no tendrá efecto alguno en otras aplicaciones de otros servidores y clústeres. Sin embargo, si este servidor de perfiles base se registra en el proceso del agente administrativo, podrá asociar el ámbito de célula con el dominio de seguridad si desea que todos los servidores del perfil base utilicen el mismo dominio de seguridad para todas sus aplicaciones de usuario. Para obtener más información, consulte Federación de un nodo con dominios de seguridad.

Puede tener un dominio de seguridad asociado a nivel de célula y también otros dominios de seguridad asociados con varios clústeres o servidores individuales (los que no forman parte de ningún clúster). En este caso, el tiempo de ejecución de seguridad primero comprueba si se ha asociado algún dominio de seguridad con el servidor o un clúster. Si se ha asociado un dominio de seguridad con el servidor o un clúster, los atributos de seguridad definidos en éste se utilizarán para todas las aplicaciones de dicho servidor o clúster. Todos los atributos de seguridad que falten de este dominio de servidor o clúster se obtendrán de la configuración de seguridad global y no de la configuración de dominio asociada con la célula.

Si el servidor o clúster no tiene definido su propio dominio, el código de tiempo de ejecución de seguridad utilizará los atributos de seguridad del dominio asociado con la célula (si se ha definido alguno). Todos los atributos de seguridad que falten del dominio de célula se heredan de la configuración de seguridad global.

Relación entre la seguridad de nivel de servidor antiguo y los nuevos dominios de seguridad

En los releases anteriores de WebSphere Application Server se podía asociar un pequeño conjunto de atributos de seguridad a nivel de servidor. Estos atributos eran utilizados por todas las aplicaciones a nivel de servidor. El modo anterior de configurar los atributos de seguridad está en desuso en WebSphere Application Server 7.0 y se eliminará en un release futuro.

Ahora debe utilizarse el nuevo soporte de dominios de seguridad en WebSphere Application Server 7.0, ya que estos dominios de seguridad se gestionan más fácilmente y son más flexibles. Por ejemplo, en versiones anteriores de WebSphere Application Server se debía asociar manualmente la misma configuración de seguridad a todos los miembros del clúster configurando los mismos atributos de seguridad para cada servidor de un clúster.

La herramienta de migración migra la información de configuración de seguridad de nivel de servidor existente a la nueva configuración de dominio de seguridad cuando la modalidad de compatibilidad de script es false (-scriptCompatibility="false"). Se crea un nuevo dominio de seguridad para cada configuración de seguridad de servidor si éste no forma parte de un clúster. Si forma parte de un clúster, se asocia un dominio de seguridad con el clúster en lugar de con todos los servidores del clúster en cuestión. En ambos casos, todos los atributos de seguridad configurados a nivel de servidor de los releases anteriores se migran a la configuración del nuevo dominio de seguridad y el ámbito adecuado se asigna a los dominios de seguridad.

Si la modalidad de compatibilidad de script se establece en true, la configuración de seguridad de nivel de servidor no se migrará a la configuración de los nuevos dominios de seguridad. La configuración de seguridad del servidor anterior se migra sin ninguna modificación. El tiempo de ejecución de seguridad detecta que existe una configuración de seguridad anterior y utiliza dicha información, aunque se haya asociado un dominio de seguridad con el servidor de forma directa o indirecta. Si la modalidad de compatibilidad de script se establece en true, elimine la configuración de seguridad del nivel de servidor y, a continuación, cree un dominio de seguridad con el mismo conjunto de atributos de seguridad.

Utilización de los atributos de seguridad de nivel de dominio por parte del tiempo de ejecución de seguridad y las aplicaciones

En esta sección, se describe cómo los atributos individuales a nivel de dominio son utilizados por el tiempo de ejecución de seguridad y cómo ello influye en la seguridad de la aplicación del usuario. Puesto que todos estos atributos de seguridad también se definen a nivel global, se puede obtener más información sobre estos atributos en cualquier otro lugar. Para la finalidad de esta sección, se pone de relieve el comportamiento a nivel de dominio.

  1. Seguridad de aplicación:

    Seleccione Habilitar seguridad de la aplicación para habilitar o inhabilitar la seguridad para las aplicaciones de usuario. Cuando esta selección está inhabilitada, todos los EJB y aplicaciones web del dominio de seguridad dejan de estar protegidos. Se otorga acceso a estos recursos sin autenticación de usuario. Al habilitar esta selección, la seguridad J2EE se aplica a todos los EJB y aplicaciones web del dominio de seguridad. La seguridad J2EE sólo se aplica cuando la seguridad global está habilitada en la configuración de seguridad global; es decir, no se puede habilitar la seguridad de la aplicación sin habilitar primero la seguridad global a nivel global.

  2. Seguridad de Java 2:

    Seleccione Utilizar seguridad de Java 2 para habilitar o inhabilitar la seguridad de Java 2 a nivel de dominio o para asignar o añadir propiedades relacionadas con la seguridad de Java 2. Esta opción habilita o inhabilita la seguridad de Java 2 a nivel de proceso (JVM) de forma que todas las aplicaciones (administrativas y de usuario) puedan habilitar o inhabilitar la seguridad de Java 2.

  3. Reino de usuarios (registro de usuarios):

    Esta sección permite configurar el registro de usuarios para el dominio de seguridad. Puede configurar separadamente cualquier registro que se utilice a nivel de dominio. Para obtener más información, consulte Configuración de atributos para dominios de seguridad.

    Al configurar un registro a nivel de dominio, se puede optar por definir un nombre de reino propio para el registro. El nombre de reino diferencia a los registros de usuarios entre sí. El nombre de reino se utiliza en varios lugares: en el panel de inicio de sesión del cliente de Java para hacer solicitudes al usuario, en la memoria caché de autenticación, y al utilizar la autorización nativa.

    A nivel de la configuración global, el sistema crea el reino para el registro de usuarios. En los releases anteriores de WebSphere Application Server sólo se configura un registro de usuarios en el sistema. Si dispone de varios dominios de seguridad, puede configurar varios registros en el sistema. Para que los reinos sean exclusivos en estos dominios, configure su nombre de reino propio para un dominio de seguridad. También puede optar por que el sistema cree un nombre de reino exclusivo si está seguro que debe serlo. En este último caso, el nombre de reino se basa en el registro que se está utilizando.

    En el caso de los registros LDAP, el host:puerto del servidor LDAP es el nombre de reino generado por el sistema. Para el sistema operativo local, el nombre de la máquina del sistema operativo local es el nombre del reino. Para los registros de usuarios personalizados, el reino es el que devuelve el método getRealm ( ) de la implementación del registro personalizado.

    Si el sistema ha generado nombres de reino suficientemente exclusivos, puede seleccionar la opción para que el sistema genere el nombre de reino. En caso negativo, seleccione un nombre de reino exclusivo para cada dominio de seguridad en el que haya configurado el registro de usuarios. Si el repositorio de usuarios subyacente es el mismo, utilice el mismo nombre de reino en diferentes dominios. Desde la perspectiva del tiempo de ejecución de seguridad, nombres de reino idénticos tienen el mismo conjunto de información sobre usuarios y grupos. Por ejemplo, cuando desde un reino se precisa de la información sobre usuarios y grupos, se utilizará el primer repositorio de usuarios que coincida con el reino.

    Si un registro de sistema operativo local que no está centralizado se configura para cualquier dominio y dicho dominio está asociado con servidores o clústeres de nodos que no están en el mismo sistema que el gestor de despliegue, se tiene que proporcionar el nombre de reino. Este nombre de reino tiene que ser el mismo que sería si se hubiera generado en el nodo. Este nombre de reino se puede obtener llamando al método getRealm() en el MBean SecurityAdmin en dicho nodo. Normalmente, el nombre de reino para los registros de sistema operativo local es el nombre de host de la máquina. En este caso, no deberá dejar que el sistema genere el nombre de reino si no que deberá obtener el nombre de reino utilizado por los procesos en el nodo.

    Si selecciona que el sistema genere el reino para el registro de sistema operativo local en el momento de la configuración de registro de usuario, se elegirá el registro de sistema operativo local utilizado por el gestor de despliegue. Si el reino configurado no coincide con el reino utilizado por los servidores, hay problemas de autorización. En este caso observe también que el domino que utiliza este registro local sólo se puede asociar con servidores y clústeres que pertenecen a nodos de la misma máquina.

    En WebSphere Application Server Versión 7.0, el registro de usuarios de repositorios federados sólo puede configurarse a nivel global y sólo tiene una instancia por célula, pero cualquier dominio puede utilizarlo configurándolo como el registro activo. En WebSphere Application Server Versión 8.0, puede configurar una instancia exclusiva de un repositorio federado a nivel de dominio en un entorno de varios dominios de seguridad.

    Cuando un dominio de seguridad se copia del nivel global, los usuarios y grupos definidos a nivel global también se copian en el dominio de seguridad. Esto también sucede cuando se copia de un dominio existente. Un dominio de seguridad recién creado que utiliza el repositorio VMM basado en archivos requiere que el usuario llene el repositorio con usuarios y grupos.

    Otra novedad de este release de WebSphere Application Server, un recuadro de selección nuevo en la página de la consola administrativa de valores de configuraciones del reino, Utilizar esquema global para el modelo, establece la opción de esquema global para el modelo de datos en un entorno de dominio de seguridad múltiple. El esquema global hace referencia al esquema del dominio admin.

    Si se está procesando más de un registro de usuarios, la función de búsqueda de nombres que utiliza “UserRegistry” como nombre de búsqueda devolverá el registro de usuarios utilizado por las aplicaciones de usuario. El registro de usuarios utilizado por las aplicaciones administrativas suele encontrarse utilizando el nombre de búsqueda “AdminUserRegistry”.

    Tal como se describe en Comunicación a través de reinos, cuando una aplicación de un reino se comunica con una aplicación de otro reino mediante señales LTPA, deberá confiarse en los reinos. La relación de confianza puede establecerse mediante el enlace de entrada Reinos de autenticación de confianza – en el panel del registro de usuarios o mediante el mandato addTrustedRealms. Puede establecer confianza entre diferentes reinos. Un usuario que ha iniciado sesión en un reino puede acceder a los recursos de otro reino. Si no se establece ninguna confianza entre dos reinos, la validación de la señal LTPA no funcionará correctamente.

    Nota: El nombre de reino utilizado en el archivo web.xml no está relacionado con el reino de registro de usuarios.
  4. Asociación de confianza:

    Cuando se configura el interceptor de asociación de confianza (TAI) a un nivel de dominio, los interceptores configurados a nivel global se copian en el nivel de dominio por comodidad. Puede modificar la lista de interceptores a nivel de dominio para adaptarla a sus necesidades. Configure únicamente los interceptores que deban utilizarse a nivel de dominio.

    Los interceptores de asociación de confianza de Tivoli Access Manager sólo se pueden configurar a nivel global. La configuración de dominio también puede utilizarlos, pero la versión de su interceptor de asociación de confianza no puede ser diferente. Sólo puede existir en la célula una instancia de los interceptores de asociación de confianza de Tivoli Access Manager.

  5. Autenticación Web de SPNEGO:

    La autenticación web SPNEGO, que permite configurar SPNEGO para la autenticación de recursos web, se puede configurar a nivel de dominio.

    Nota: En WebSphere Application Server Versión 6.1, se introdujo un TAI (TAI) que utiliza el mecanismo SPNEGO (Simple and Protected GSS-API Negotiation) para negociar y autenticar con seguridad solicitudes HTTP de recursos seguros. En WebSphere Application Server 7.0, esta función está en desuso. La autenticación web SPNEGO ha ocupado su lugar para proporcionar la recarga dinámica de filtros SPNEGO y para habilitar la recuperación para el método de inicio de sesión de la aplicación.
  6. Seguridad RMI/IIOP (CSIv2):

    El atributo de seguridad RMI/IIOP hace referencia a las propiedades del protocolo CSIv2 (Common Secure Interoperability Versión 2). Cuando configura estos atributos a nivel de dominio, se copia la configuración de seguridad RMI/IIOP a nivel global para mayor comodidad.

    Puede cambiar los atributos que deban ser distintos a nivel de dominio. Los valores de la capa de transporte para las comunicaciones de entrada CSIv2 deben ser los mismos para el nivel global y el nivel de dominio. Si son diferentes, los atributos de nivel de dominio se aplicarán a todas las aplicaciones en el proceso.

    Cuando un proceso se comunica con otro proceso con otro reino, la autenticación LTPA y las señales de propagación no se propagan al servidor en sentido descendente a menos que dicho servidor aparezca en la lista de reinos de confianza de salida. Esto puede hacerse mediante el enlace de salida Reinos de autenticación de confianza – en el panel Comunicación de salida de CSIv2 o utilizando la tarea de mandato addTrustedRealms. Consulte Comunicación a través de reinos para obtener más información.

  7. JAAS (Java Authentication and Authorization Service):

    Los inicios de sesión de la aplicación JAAS, inicios de sesión del sistema JAAS y alias de datos de autenticación JAAS J2C se pueden configurar a nivel de dominio. De manera predeterminada, todas las aplicaciones del sistema tienen acceso a los inicios de sesión JAAS configurados a nivel global. El tiempo de ejecución de seguridad busca primero los inicios de sesión JAAS a nivel de dominio. Si no los encuentra, los busca en la configuración de seguridad global. Configure cualquiera de estos inicios de sesión JAAS en un dominio sólo cuando deba especificar un inicio de sesión que sea utilizado exclusivamente por las aplicaciones del dominio de seguridad.

    Sólo en el caso de las propiedades JAAS y personalizadas, una vez que se han personalizado los atributos globales para un dominio, pueden seguir siendo utilizados por las aplicaciones de usuario.

  8. Java Authentication SPI (JASPI)

    Especifica los valores de configuración de un proveedor de autenticación JASPI (Java Authentication SPI) y los módulos de autenticación asociados que se van a aplicar a nivel de dominio.

    Seleccione Proveedores para crear o editar un proveedor de autenticación JASPI.

    Nota: El proveedor de autenticación JASPI se puede habilitar con proveedores configurados en el nivel de dominio. De manera predeterminada, todas las aplicaciones del sistema tienen acceso a los proveedores de autenticación de JASPI configurados a nivel global. El tiempo de ejecución de seguridad busca primero los proveedores de autenticación de JASPI a nivel de dominio. Si no los encuentra, los busca en la configuración de seguridad global. Configure los proveedores de autenticación JASPI en un dominio sólo cuando el proveedor se va a utilizar exclusivamente por las aplicaciones en dicho dominio de seguridad.
  9. Atributos de mecanismo de autenticación:

    Especifica los distintos valores de memoria caché que deben aplicarse a nivel de dominio.

    1. Valores de memoria caché de autenticación - utilice esta opción para especificar los valores de memoria caché de autenticación. La configuración especificada en este panel sólo se aplica a este dominio.
    2. Tiempo de espera LTPA - Puede configurar un valor de tiempo de espera LTPA diferente a nivel de dominio. El valor de tiempo de espera predeterminado es 120 minutos, que se establece a nivel global. Si se establece el tiempo de espera LTPA a nivel de dominio, cualquier señal que se cree en el dominio de seguridad cuando se acceda a aplicaciones de usuario se creará con este tiempo de caducidad.
    3. Utilizar nombres de usuarios calificados por reino - Cuando se habilita esta selección, los nombres de usuario devueltos por los métodos como getUserPrincipal( ) se califican con el reino de seguridad (registro de usuarios) que utilizan las aplicaciones del dominio de seguridad.
  10. Proveedor de autorización:

    Puede configurar a nivel de dominio un proveedor de JACC (Java Authorization Contract for Containers) externo de otra empresa. El proveedor JACC de Tivoli Access Manager sólo se puede configurar a nivel global. Los dominios de seguridad lo podrán seguir utilizando si no alteran temporalmente el proveedor de autorización con otro proveedor de JACC.

    Los atributos JACC, por ejemplo el objeto de política, están basados a nivel de JVM. Esto implica que sólo puede haber un objeto de política JACC en un proceso de JVM. Sin embargo, cuando se tienen varios proveedores de JACC configurados, el proceso de gestor de despliegue tiene que manejar todos estos proveedores en la misma JVM porque tiene que propagar la política de autorización de las aplicaciones al proveedor respectivo basándose en el nombre de aplicación.

    Si el proveedor de JACC puede manejar la propagación de la política de autorización a varios proveedores, puede configurarlo a nivel global. En este caso, cuando se instala una aplicación, se llama a este proveedor de JACC en el proceso de gestor de despliegue y es responsabilidad de este proveedor de JACC propagar la información al proveedor de JACC correspondiente basándose en el nombre de aplicación pasado en el ID de contexto.

    Otra manera de realizar esta tarea consiste en establecer la propiedad personalizada, com.ibm.websphere.security.allowMultipleJaccProviders=true, a nivel de seguridad global. Cuando se establece esta propiedad, WebSphere Application Server propaga la información de política de autorización al proveedor de JACC asociado con el dominio que corresponde al servidor de destino donde está instalada la aplicación. Esta propiedad sólo se utiliza en el proceso de gestor de despliegue porque los servidores gestionados no contienen varios proveedores de JACC.

    [z/OS]También puede configurar las opciones de autorización SAF a nivel de dominio de seguridad, que son las siguientes:
    • El ID de usuario autenticado
    • El correlacionador de perfiles SAF
    • Posibilidad de habilitar la delegación SAF
    • Si se debe utilizar el perfil APPL para restringir el acceso a WebSphere Application Server.
    • Posibilidad de suprimir los mensajes de error de autenticación
    • La estrategia de registro de auditoría SMF
    • El prefijo de perfil SAF

    [z/OS]Las comprobaciones CBIND se consideran operaciones administrativas y, por consiguiente, el valor de nivel global del prefijo de perfil de SAF que se especifica, se utiliza al determinar el nombre del recurso CBIND que se debe comprobar. Por ejemplo: CB.BIND.<nombre_clústero prefijo_perfil_SAF>.

    [z/OS]Para obtener más información sobre las opciones de autorización SAF, lea Autorización SAF (System Authorization Facility) de z/OS.

  11. Propiedades personalizadas:

    Establezca propiedades personalizadas a nivel de dominio que sean nuevas o distintas de las del nivel global. De manera predeterminada, todas las aplicaciones de la célula pueden acceder a todas las propiedades personalizadas de la configuración de seguridad global. El código de tiempo de ejecución de seguridad busca primero la propiedad personalizada a nivel de dominio. Si no la encuentra, intenta obtenerla de la configuración de seguridad global.

    Sólo en el caso de las propiedades JAAS y personalizadas, una vez que se han personalizado los atributos globales para un dominio, pueden seguir siendo utilizados por las aplicaciones de usuario.

Modelo de programación de seguridad de cliente y aplicación al utilizar dominios de seguridad

un cliente o aplicación Java que actúa como cliente que acceso a un EJB normalmente realiza la búsqueda de denominación en primer lugar. El recurso de denominación, utilizado por las aplicaciones administrativas y de usuario, se considera como un recurso administrativo. Está protegido por la información de la configuración de seguridad global. En una configuración de varios dominios donde la seguridad global utiliza un reino (el registro de usuarios) y un dominio utiliza otro reino, el cliente Java debe autenticar en dos reinos diferentes. La primera configuración es necesaria para el reino de la configuración de seguridad global de modo que la operación de denominación se lleve a cabo correctamente y la segunda autenticación es necesaria para acceder al EJB, que utiliza otro reino.

El rol CosNamingRead protege todas las operaciones de lectura de denominación. A este rol suele asignársele el asunto especial Todos. Esto implica que cualquier usuario, válido o no, puede buscar el espacio de nombres. Cuando se definen varios dominios, si se ha asignado el rol CosNamingRead al asunto especial Todos, el código de tiempo de ejecución de seguridad del lado del cliente no le solicitará que inicie sesión. En su lugar, utilizará el asunto UNAUTHENTICATED para acceder a la operación de denominación. Una vez que se haya completado la operación de búsqueda de denominación, cuando el cliente intente acceder al EJB, aparecerá un panel de inicio de sesión que indica el reino actualmente utilizado por la aplicación EJB (es decir, el reino utilizado en el dominio). A continuación, el cliente presenta las credenciales de usuario adecuadas para dicho reino, las cuales podrán entonces acceder al EJB. Esta lógica se aplica a todas las variaciones del origen de inicio de sesión, incluidas properties y stdin, no sólo cuando el origen de inicio de sesión está establecido en prompt.

Si el asunto especial Todos se ha eliminado del rol CosNamingRead, el mensaje de solicitud de inicio de sesión aparecerá dos veces. Si el origen de inicio de sesión es properties, puede eliminar los comentarios de la propiedadcom.ibm.CORBA.loginRealm en el archivo $WAS_HOME/profiles/$ProfileName/properties/sas.client.props y añadir los reinos adecuados utilizando “|” como separador. También deberá introducir los usuarios y contraseñas correspondientes en las propiedades com.ibm.CORBA.loginUserid y com.ibm.CORBA.loginPassword respectivamente. Al utilizar el inicio de sesión mediante programación en el código de cliente Java, deberá realizar la autenticación dos veces con otras credenciales de usuario; una vez antes de realizar la búsqueda de denominación del EJB (el usuario debe encontrarse en el reino global) y más adelante antes de llamar a cualquier método del EJB (el usuario debe estar en el reino del dominio EJB).

[z/OS]No se hace referencia al rol CosNamingRead definido en el servidor de seguridad de z/OS para determinar si las operaciones de lectura de denominación están protegidas en un entorno de dominio de multi seguridad, aunque esté habilitada la autorización SAF. En lugar de ello, se utilizan los valores del archivo admin-authz.xml. De manera alternativa, puede utilizar la propiedad personalizada com.ibm.security.multiDomain.setNamingReadUnprotected para controlar las operaciones de lectura de denominación están protegidas. Esta propiedad altera temporalmente las asignaciones realizadas en el rol CosNamingRead, independientemente del proveedor de autorización que se utilice.

En general, cuando un cliente Java debe autenticarse en varios y diferentes reinos, debe proporcionar la información de credenciales de todos estos reinos. Si el origen de inicio de sesión es prompt o stdin, se le solicitará que inicie sesión varias veces, una por cada reino. Si el origen de inicio de sesión se establece en properties, las propiedades adecuadas del archivo sas.client.props (o de cualquier archivo relacionado) se utilizarán para autenticar en diferentes reinos.

En determinados escenarios, un cliente puede realizar varias llamadas al mismo reino. Por ejemplo, el cliente Java puede acceder a un recurso mediante realm1, acceder seguidamente a un recurso mediante realm2 y, a continuación, volver a acceder a un recurso en realm1. En este caso, se solicita al cliente que inicie sesión tres veces; la primera para realm1, la segunda para realm2 y, finalmente, para realm1 otra vez.

De manera predeterminada, el código del lado del cliente no coloca en memoria caché el asunto que se utiliza para iniciar sesión en un reino. Si se encuentra en este escenario y desea que el cliente coloque en memoria caché el asunto basado en el reino, establezca la propiedad com.ibm.CSI.isRealmSubjectLookupEnabled en true en el archivo sas.client.props. Si se establece la propiedad com.ibm.CSI.isRealmSubjectLookupEnabled, el código de cliente colocará en memoria caché el asunto basado en el nombre del reino. La próxima vez que el cliente Java deba autenticar en este reino, se buscará la memoria caché para obtener el sujeto y no se solicitará al cliente que inicie sesión. Además, cuando se establece la propiedad com.ibm.CSI.isRealmSubjectLookupEnabled, se utilizará el mismo asunto con el que se inició sesión la primera vez para los inicios de sesión posteriores. Si debe modificar la información del asunto, no establezca esta propiedad.

Si el cliente realiza un inicio de sesión mediante programación, podrá pasar el reino junto con el usuario y la contraseña que debe autenticar. En este caso, cuando la propiedad com.ibm.CORBA.validateBasicAuth se establezca en true (el valor predeterminado) en el archivo sas.client.props, el registro que coincida con el nombre de reino se utilizará para el inicio de sesión. Dicho reino deberá soportarse en el proceso en el que se lleve a cabo la autenticación.

Al utilizar las configuraciones JAAS WSLogin, también deberá establecer la opción use_realm_callback del archivo wsjaas_client.config en $WAS_HOME/profiles/$ProfileName/properties para que el nombre del reino se pase al manejador de devolución de llamada. Si desea especificar otra URL de proveedor para el servidor de nombres, establezca la opción use_appcontext_callback y pase las propiedades de URL de proveedor en una correlación hash a WSLogin.

Si no conoce el nombre del reino, utilice el nombre <default>. La autenticación se realiza con el reino de la aplicación. Si la operación de lectura de denominación no tiene asignado el asunto especial Todos, deberá proporcionar el reino utilizado por las aplicaciones administrativas (el registro utilizado en la configuración de seguridad global), así como la información de usuario y contraseña adecuada de dicho registro para que la operación de búsqueda se lleve a cabo correctamente.

Una vez que dicha operación se haya realizado correctamente, lleve a cabo otro inicio de sesión mediante programación proporcionando el reino de la aplicación (o <default>) y la información de usuario y contraseña del usuario adecuado del registro utilizado por la aplicación. Este proceso es similar a cuando el origen de inicio de sesión es prompt. Debe llevar a cabo la autenticación dos veces, una para el registro utilizado por la configuración de seguridad global (para la operación de búsqueda de denominación) y otra para el registro utilizado por la aplicación para acceder al EJB.

Si com.ibm.CORBA.validateBasicAuth se establece en false en el archivo $WAS_HOME/profiles/$ProfileName/properties/sas.client.props, el inicio de sesión mediante programación podrá utilizar <default> como nombre de reino para las operaciones de búsqueda y de EJB. La autenticación real se lleva a cabo cuando se accede al recurso en el lado del servidor, en cuyo caso el reino se calculará según el recurso al que se acceda.

El soporte del nuevo dominio de seguridad a partir de WebSphere Application Versión 7.0 no cambia el modelo de programación de seguridad de aplicación actual. Sin embargo, proporciona una mayor flexibilidad y más capacidades como las siguientes:

  • Las aplicaciones de usuario pueden seguir encontrando el objeto del registro de usuarios mediante la búsqueda de denominación de “UserRegistry”. En el caso del objeto de registro utilizado por las aplicaciones administrativas, se puede utilizar la búsqueda de denominación de “AdminUserRegistry”
  • El uso de la aplicación de la configuración de inicio de sesión JAAS no cambia en una configuración de varios dominios. Sin embargo, si una aplicación debe hacer referencia a la configuración JAAS especificada a nivel de dominio, el administrador y el desplegador de dicha aplicación deberán asegurarse de que este dominio se configura con las configuraciones JAAS requeridas por la aplicación.
  • Si una aplicación debe comunicarse con otras aplicaciones mediante diferentes reinos, deberá establecerse la relación de confianza tanto para las comunicaciones de entrada como las de salida al utilizar señales LTPA. Consulte Comunicación a través de reinos para obtener más información.
  • Al utilizar el inicio de sesión mediante programación en las aplicaciones, si desea iniciar sesión en el reino utilizado por la aplicación, utilice <default> como nombre de reino o proporcione el que utiliza la aplicación. Si debe iniciar sesión en el reino global, deberá proporcionar el nombre de reino global. Si proporciona cualquier otro reino, sólo se creará el asunto de autenticación básica. Cuando la solicitud fluye hacia el servidor que alberga el reino en cuestión, la autenticación real del usuario se llevará a cabo si el servidor alberga el reino. Si el servidor no alberga el reino, el inicio de sesión no se llevará a cabo correctamente.

Despliegue de aplicaciones en configuraciones de varios dominios

Al desplegar una aplicación en un configuración de varios dominios, todos los módulos de la aplicación deberán instalarse en los servidores o clústeres que pertenecen al mismo dominio de seguridad. En caso contrario, en función de los atributos de seguridad configurados en estos dominios de seguridad, es posible que se de lugar a comportamiento incoherente. Por ejemplo, si los dominios contienen diferentes registros de usuario, la información de usuarios y grupos podrá ser diferentes, lo cual puede provocar un comportamiento incoherente al acceder a los módulos. Otro ejemplo es cuando los datos JAAS son diferentes entre los dominios de seguridad. No es posible acceder a las configuraciones JAAS desde todos los módulos de la aplicación. El código de tiempo de ejecución y las tareas de mandato se basan en el dominio que se asocia a una aplicación cuando se trata con atributos como, por ejemplo, el registro de usuarios, las configuraciones de inicio de sesión JAAS, los datos de autenticación J2C y la autorización.

En la mayoría de casos, el despliegue de aplicaciones no se lleva a cabo correctamente cuando una aplicación se despliega en diferentes dominios. Sin embargo, ya que esto empezó a ser posible en releases anteriores de WebSphere Application Server cuando sólo se daba soporte a unos pocos atributos a nivel de servidor, la herramienta de despliegue primero busca atributos configurados en los dominios. Si los atributos del dominio son los mismos que los que se soportan en los releases anteriores, la consola administrativa solicitará confirmación para asegurarse de que desea desplegar módulos de aplicación en varios dominios de seguridad. A no ser que exista un requisito absoluto de desplegar las aplicaciones en diferentes dominios, detenga el despliegue y seleccione los servidores y clústeres en el mismo dominio de seguridad.

Comunicación a través de reinos

Cuando las aplicaciones se comunican mediante el protocolo RMI/IIOP y se utiliza el mecanismo de autenticación LTPA, la señal LTPA pasará entre los servidores implicados. La señal LTPA contiene el ID exclusivo calificado por reino, (también llamado ID de acceso), del usuario que inicia sesión en la aplicación frontal. Cuando el servidor en sentido descendente recibe esta señal, intentará descrifrarlo. Si las claves LTPA se comparten entre dos servidores, el descifrado se llevará a cabo correctamente y el ID de acceso del usuario se podrá obtener de la señal. El reino del ID de acceso se comprueba con el reino actual utilizado por la aplicación. Si los reinos coinciden, la validación de la señal LTPA se llevará a cabo correctamente y se continuará con la autenticación. Si los dominios no coinciden, la validación de señales falla, dado que el usuario del reino foráneo no puede validarse en el reino actual de la aplicación. Si se supone que las aplicaciones no deben comunicarse entre sí al utilizar el protocolo RMI/IIOP y el mecanismo de autenticación LTPA, no tendrá que llevar a cabo ninguna operación más.

Si no desea que la comunicación entre reinos se lleve a cabo correctamente al utilizar las señales de RMI/IIOP y LTPA, primero deberá establecer la confianza entre los reinos implicados, tanto para las comunicaciones de entrada como las de salida.

Para el servidor que origina la solicitud, su reino debe tener los reinos en los que se puede confiar para enviarles la señal. Esto se conoce como outboundTrustedRealms. El reino del servidor que recibe la solicitud debe confiar en los reinos de los que puede recibir señales LTPA. Esto se conoce como inboundTrustedRealms.

Los reinos de confianza de salida pueden establecerse mediante el mandato addTrustedRealms con la opción –communicationType establecida en salida. También puede establecerse en la consola administrativa pulsando la opción Reinos de autenticación de confianza - salida en el panel Comunicaciones de salida CSIv2.

Los reinos de confianza de entrada pueden establecerse mediante el mismo mandato addTrustedRealms con la opción –communicationType establecida en entrada. También puede establecerse mediante la consola administrativa.

En la figura posteriormente en este apartado se muestra la comunicación entre aplicaciones que utilizan diferentes reinos (registros) mediante RMI/IIOP. En este ejemplo, la aplicación app1 (por ejemplo, un servlet) se configura para utilizar el registro de usuarios realm1. La aplicación app2 (por ejemplo, un EJB) se configura para utilizar el registro de usuarios realm2. El usuario (user1) inicialmente inicia sesión en el servlet de app1, el cual, a continuación, intenta acceder a un EJB de app2. Debe establecerse lo siguiente:

  • En Domain1, realm1 debe confiar en realm2 para la comunicación de salida.
  • En Domain2, realm2 debe confiar en realm1 para la comunicación de entrada.
  • El ID de acceso de user1 debe configurarse en la tabla de autorizaciones de app2.

Cuando app2 recibe la señal LTPA que contiene el ID de acceso de user1, deberá descifrar la señal. Ambos servidores comparten las mismas claves LTPA. A continuación, la señal LTPA se asegura de que el reino foráneo es de confianza y lleva a cabo la autorización basada en el ID de acceso de user1. Si no se inhabilita la propagación de atributos de seguridad, la información de grupo de user1 también se propagará en app2. Los grupos se pueden utilizar para la comprobación de autorización, siempre que la tabla de autorizaciones contenga la información de grupo. Puede asociar un asunto especial, AllAuthenticatedInTrustedRealms, con los roles en lugar de añadir usuarios y grupos individuales a la tabla de autorizaciones.

Si las aplicaciones del ejemplo anterior se despliegan en diferentes células, deberá llevar a cabo lo siguiente:

  • Comparta las claves LTPA entre las células.
  • Actualice la tabla de autorizaciones de app2 con ID de acceso de usuarios y grupos foráneos mediante el programa de utilidad wsadmin. La consola administrativa no tiene acceso a los reinos fuera del ámbito de la célula.
Figura 4. Comunicación entre reinos en un entorno de varios reinos Si las aplicaciones del ejemplo anterior se despliegan en células diferentes, debe realizar lo siguiente: comparta las claves LTPA entre las células y actualice la tabla de autorizaciones para app2 con ID de acceso de usuarios y grupos externos utilizando el programa de utilidad wsadmin. La consola administrativa no tiene que acceder a los reinos fuera del ámbito de la célula.

Una vez que se ha establecido la confianza entre los reinos, cuando el servidor recibe la señal LTPA y ésta se descifra, comprueba si el reino foráneo se encuentra en la lista de reinos de confianza de entrada. Si es de confianza, la autenticación se llevará a cabo correctamente. Sin embargo, puesto que se trata de un reino foráneo, no realiza una búsqueda en el registro de usuarios para recopilar información sobre el usuario. La información que haya en la señal LTPA se utilizará para autorizar al usuario.

La única información de la señal LTPA es el ID exclusivo del usuario. Este ID exclusivo del usuario debe existir en la tabla de autorizaciones de esta aplicación. En el caso de que exista, la autenticación se llevará a cabo correctamente. Sin embargo, si se habilita la propagación de atributos, se envían atributos de autorización adicionales (grupos a los que pertenece este usuario) del usuario desde el servidor de origen al servidor de destino. Estos atributos adicionales se utilizan para tomar decisiones relacionadas con el acceso. Si las señales de propagación contienen información de grupos, ésta se utilizará al tomar una decisión relacionada con la autorización.

Como se ha mencionado anteriormente, la información sobre usuarios o grupos de los reinos de confianza debe constar en la tabla de autorizaciones de la aplicación receptora. Específicamente, el ID de acceso de los usuarios o grupos debe estar en el archivo de enlace de la aplicación. Éste debe ser el caso cuando se despliega la aplicación. En la consola administrativa, cuando se despliega una aplicación en un dominio, se pueden añadir ID de usuario de los usuarios y grupos de cualquier de los reinos de confianza a la tabla de autorizaciones.

También puede asociar un asunto especial, AllAuthenticatedInTrustedRealms, a los roles en lugar de añadir usuarios y grupos individuales. Esto es parecido al sujeto especial AllAuthenticated soportado actualmente. La diferencia está en que el asunto especial AllAuthenticated hace referencia a los usuarios del mismo reino que la aplicación, mientras que el asunto especial AllAuthenticatedInTrustedRealms se aplica a todos los usuarios de los reinos de confianza y del reino de la aplicación.

Puede asociar el ID de acceso mediante el script de instalación $AdminApp. Puesto que el ID de acceso utiliza un formato exclusivo, utilice la tarea de mandato listRegistryUsers con displayAccessIds establecido en true. Si se especifica un nombre o formato no válido en este campo, la autorización no se llevará a cabo correctamente.

El gestor de despliegue obtiene la información de usuarios y grupo de los reinos de confianza ya que tiene acceso a todas las configuraciones de registro de usuarios de todos los dominios. Sin embargo, en determinadas situaciones, no es posible obtener dicha información.

Por ejemplo, si un servidor albergado en un nodo externo utiliza un sistema operativo local como registro para su dominio, el gestor de despliegue no podrá obtener la información de usuarios y grupo a menos que se ejecute en la misma configuración del sistema operativo. Deberá ponerse en contacto con el sistema operativo externo para obtener esta información. Esto puede realizarse directamente invocando al registro en el servidor asociado con dicho dominio. Los servidores asociados con el dominio deben iniciarse para que este procedimiento funcione. También debe establecer la propiedad, com.ibm.websphere.allowRegistryLookupOnProcess, en true en las propiedades personalizadas de seguridad de nivel superior. Cuando se establece esta propiedad, el código del gestor de despliegue buscará uno de los servidores asociado con el dominio de seguridad y obtendrá la información de usuarios y grupos directamente de éste. Esto se puede llevar a cabo llamando a un MBean de uno de los servidores.

Si no se puede acceder el MBean de ninguno de los servidores que utilizan el dominio, la consola administrativa mostrará un panel en el que puede especificar la información de usuario y de ID de acceso manualmente para cada usuario y grupo. Es importante especificar el formato de ID de acceso adecuado en este campo. El formato del ID de acceso para el usuario es user:realmName/userUniqueId. RealName es el nombre del reino donde se encuentra el usuario y userUniqueId es el ID exclusivo que representa al usuario, en función del registro que se utilice.

Por ejemplo, para LDPA, el ID de usuario exclusivo es el nombre distinguido (DN), para el sistema operativo local de Windows y es el SID del usuario. Para las plataformas Unix, es el UID. Para los registros personalizados, depende de la implementación.

De forma similar, para grupos, el formato del ID de acceso es:realmName/groupUniqueId. Como se ha mencionado anteriormente, utilice los mandatos listRegistryUsers y listRegistryGroups con la opción –displayAccessIds establecida en true de modo que pueda obtener el formato adecuado para el dominio o reino que le interesa.

Una vez que se agregan los usuarios y grupos de los reinos de confianza o el asunto especial AllAuthenticatedInTrustedRealms a la tabla de autorizaciones de la aplicación, ya podrá aceptar solicitudes de otras aplicaciones que utilicen cualquier de los reinos de confianza. La validación de señal LTPA del servidor receptor primero realiza una comprobación para asegurarse de que el reino es de confianza. A continuación, el motor de autorización comprueba si el usuario y/o los usuarios externos o el asunto especial AllAuthenticatedInTrustedRealms tienen acceso a los roles necesarios para acceder al recurso. Si el valor es true, se concederá el acceso.

La comunicación a través de reinos sólo se puede aplicar al utilizar la autorización incorporada de WebSphere. Si utiliza otro motor de autorización que incluye SAF para z/OS, se podrá establecer cualquier comunicación a través de reinos mediante la implementación de módulos de inicio de sesión personalizados que correlacionen usuarios externos con usuarios en su propio repositorio.

Federación de un nodo con dominios de seguridad

Cuando se configura un dominio de seguridad en la versión base y se federa para una célula, el dominio de seguridad configurado en la versión base también se configurará para dicho servidor de la célula. La misma configuración de seguridad de dominio puede ser utilizada por el servidor antes y después de la federación. Si un servidor base debe federarse a una célula, el recurso asignado al dominio de seguridad deberá ser el ámbito del servidor en lugar del ámbito de la célula.

Si se espera registrar el servidor base con un proceso de agente administrativo, utilice el ámbito de célula como recurso si tiene la intención de que todos los servidores del perfil base utilicen este dominio de seguridad.

Si durante la federación, el dominio de seguridad de la base ya existe a nivel de célula, el mandato addNode no se llevará a cabo correctamente. Puede utilizar la opción –excludesecuritydomains para no incluir el dominio de seguridad durante la federación.

Cuando el nodo federado se elimina de un célula, los recursos de dicho nodo deberán eliminarse de los dominios de seguridad. Si los dominios de seguridad tienen asociados clústeres que abarcan nodos, los nodos no se eliminarán. Siempre puede eliminar recursos de los dominios de seguridad o dominios que no se utilicen mediante los mandatos de scripts o la consola administrativa.

Dominios de seguridad en un entorno de versiones mixtas

Una vez que todos los nodos se hayan migrado a la última versión deberá crear dominios de seguridad. Esto es especialmente adecuado si debe asociarse la célula con un dominio. Sin embargo, si desea crear dominios de seguridad en un entorno de versiones mixtas, tenga en cuenta lo siguiente:

  • Si se crea un dominio de toda la célula en una configuración de versión mixta, se creará un dominio llamado PassThroughToGlobalSecurity automáticamente. Todos los clústeres mixtos se asignarán a este dominio al crear el dominio de toda la célula. Este dominio PassThroughToGlobalSecurity es especial en el sentido de que no se le puede añadir ningún atributo, sólo recursos.

    Todos los recursos asignados al dominio PassThroughToGlobalSecurity utilizan la información de la configuración de seguridad global. Siempre que un nodo de la configuración de versión mixta se migre a la última versión, los servidores y clústeres de estos nodos se añadirán a este dominio. Las aplicaciones de todos los servidores y clústeres de estos nodos no utilizan el dominio de toda la célula. En lugar de ello, utilizan la configuración de seguridad global antes y después de la migración.

    Si ninguno de estos servidores necesita utilizar el dominio de toda la célula, deberá eliminar estos recursos de este dominio PassThroughToGlobalSecurity. Los nuevos servidores y clústeres que se crean en el nodo migrado utilizan el dominio de toda la célula, no el dominio PassThroughToGlobalSecurity. Como resultado, tendrá una combinación de servidores y clústeres, algunos de los cuales utilizarán la configuración de seguridad global y otros el dominio de toda la célula.

  • Una vez que se haya creado un dominio de toda la célula, se restringirá la adición de cualquiera de los miembros de clúster de la versión anterior al clúster de WebSphere Application Server Versión 9.0, ya que esta acción lo convertiría en un clúster mixto. Esta restricción también se aplica cuando se asocia un WebSphere Application Server Versión 9.0 con un dominio y un miembro de clúster de la versión anterior se añade a este clúster. Esta restricción es necesaria para evitar asociar un dominio de seguridad con un clúster mixto.
  • Si es posible, deberá crear un dominio de toda la célula una vez que se hayan migrado todos los nodos. En este caso, el dominio de toda la célula se puede aplicar a toda la célula y no sólo a partes de ésta. De este modo, ya no es necesario crear el dominio PassThroughToGlobalSecurity y el escenario de clúster mixto con los dominios de seguridad.

Modificación de dominios de seguridad

Utilice las tareas de la consola administrativa o los mandatos de scripts para modificar dominios de seguridad. Para obtener una lista completa de las tareas administrativas y los mandatos de scripts, consulte los enlaces de "Tareas relacionadas" al final de este documento.

Una vez que se haya creado un dominio de seguridad y se haya asociado con un conjunto de ámbitos, deberá reiniciar los servidores asociados con este nuevo dominio. Tras el reinicio, las aplicaciones de los ámbitos asociadas con el nuevo dominio utilizarán los atributos de seguridad definidos en el dominio.

Para que se aplique cualquier modificación de los atributos de dominio, deberá reiniciar todos los ámbitos que tenga asignados. También deberán reiniciarse todos los nuevos ámbitos que se añadan. Cualquier modificación en la configuración del dominio, ya sea en los atributos de seguridad o en los ámbitos, tiene impacto en las aplicaciones que utilizan la configuración del dominio.

Antes de llevar a cabo modificaciones en un dominio existente, tenga en cuenta los posibles impactos siguientes. Por ejemplo, si se elimina un registro de usuarios en un dominio y se reinician los servidores, se utilizará el registro de usuarios del dominio de toda la célula (si se ha definido alguno) o la configuración de seguridad global. Esto puede afectar a la autenticación y la autorización de la aplicación. Es posible que los usuarios y grupos asociados con una aplicación dejen de ser válidos en el nuevo registro. Otro ejemplo que debe tenerse en cuenta es cuando se eliminan configuraciones JAAS de un dominio. Las aplicaciones que se basan en esto ya no pueden utilizar las configuraciones JAAS. Cuando se modifica una configuración de seguridad, es posible que dicha modificación afecte a las aplicaciones, por lo cual todas las modificaciones en la configuración de seguridad deben llevarse a cabo con suma atención.

[z/OS]

PTF de tolerancia para entornos de releases combinados

Los PTF de tolerancia son necesarios para entornos de releases combinados en los que las versiones anteriores de clientes IIOP de WebSphere Application Server para z/OS interoperan con un servidor de aplicaciones de WebSphere Application Server Versión 9.0 para z/OS que alberga varios dominios de seguridad.

Debe actualizarse el código de procesamiento de ubicación de IIOP del cliente de IIOP anterior a la Versión 9.0 para llevar a cabo ubicaciones de IIOP en los dominios de seguridad de un servidor de aplicaciones con la Versión 9.0.

Los PTF de tolerancia de todos los releases de servicio afectados se muestran posteriormente en esta sección. El cliente IIOP anterior a la Versión 9.0 debe encontrarse en el nivel de servicio proporcionado, o un nivel posterior, para interoperar correctamente con un servidor de aplicaciones de la Versión 9.0 que contenga varios dominios de seguridad.

WebSphere Application Server para z/OS 5.1: W510246
WebSphere Application Server for z/OS v6.0: 602.29
WebSphere Application Server para z/OS v6.1: 610.17

Este requisito sólo se aplica a clientes IIOP de WebSphere para z/OS que invocan solicitudes en un servidor de aplicaciones WebSphere para z/OS con varios dominios de seguridad configurados y habilitados.


Icon that indicates the type of topic Concept topic



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