Seguridad basada en temas

Utilice la seguridad basada en temas para controlar qué aplicaciones del sistema de publicación/suscripción pueden acceder a la información de cada tema.

Para cada tema al que desee restringir el acceso, puede especificar qué principales (los ID de usuario y grupos de ID de usuario) pueden publicar en el tema y qué principales pueden suscribirse al tema. También puede especificar qué principales pueden solicitar la entrega persistente de mensajes.

Cualquier principal puede publicar, suscribir y solicitar la entrega persistente de mensajes sobre cualquier tema cuyo acceso no se haya restringido explícitamente.

La seguridad basada en temas la gestiona un Servidor de nombres de usuario que utiliza las listas de control de acceso (ACL) creadas por el usuario para decidir qué autorizaciones se aplican.

Principales y el servidor de nombres de usuario

El Servidor de nombres de usuario de WebSphere Message Broker gestiona el conjunto de principales que ya se han definido en la red siguiendo las indicaciones de los intermediarios y del Gestor de configuración, para utilizarlos en la publicación/suscripción. En Windows, esta lista de usuarios se toma del dominio especificado en el mandato mqsicreateusernameserver.

El Servidor de nombres de usuario se da a conocer al intermediario y al Gestor de configuración especificando el gestor de colas del Servidor de nombres de usuario en los mandatos mqsicreatebroker y mqsicreateconfigmgr.

Los intermediarios de mensajes del dominio de intermediarios interactúan con el Servidor de nombres de usuario para recuperar el conjunto total de usuarios y grupos a partir de los cuales se crean las listas de control de acceso y con los cuales se validan las peticiones de publicación/suscripción. El Gestor de configuración interactúa con el Servidor de nombres de usuario para mostrar los usuarios y los grupos de usuarios de las ACL que se crean utilizando el Editor de jerarquía de temas que se proporciona en la Perspectiva de Administración de intermediarios del entorno de trabajo.

Listas de control de acceso

Las listas de control de acceso se utilizan para definir, para cualquier tema y principal, el derecho de dicho principal a publicar en dicho tema suscribirse al mismo, o a solicitar la entrega persistente de una publicación sobre dicho tema.

La ACL también se puede utilizar para definir el nivel de protección de mensajes que se desee aplicar a cada tema.

Especifique esas definiciones utilizando el Editor de jerarquía de temas en la Perspectiva de Administración de intermediarios del entorno de trabajo.

El control de acceso puede establecerse explícitamente para cada tema individual. No obstante, si no se ha definido ninguna ACL explícita para un tema, el control de acceso se hereda de un tema ascendiente o padre, según lo definido en la estructura jerárquica del árbol de temas. Si ningún tema de la jerarquía hasta llegar al tema raíz tiene una ACL explícita, el tema hereda la ACL del tema raíz.

Cualquier principal definido que el Servidor de nombres de usuario conozca, puede asociarse a un tema de esta forma.

Resolución de problemas con las ACL

Si los principales del dominio de intermediarios incluyen uno o más usuarios en más de un grupo, los valores heredados o explícitos de una ACL podrían dar problemas. Las siguientes normas indican cómo resolver estos problemas:
  • Si el usuario tiene una ACL explícita de usuario sobre el tema que interesa, ésta tendrá siempre prioridad y el intermediario verificará la operación actual sobre dicha base.
  • Si el usuario no tiene una ACL explícita de usuario sobre el tema que interesa, pero tiene ACL explícitas de usuario para un ascendiente del árbol de temas, la ACL del ascendiente más cercano para dicho usuario tendrá prioridad y el intermediario verificará la operación actual sobre dicha base.
  • Si no hay ninguna ACL explícita de usuario para el usuario sobre el tema que interesa o sus ascendientes, el intermediario intentará verificar la operación actual sobre la base de ACL de grupo.
    • Si el usuario es miembro de un grupo que tiene una ACL explícita de grupo sobre el tema que interesa, ésta tendrá el intermediario verificará la operación actual sobre la base de dicha ACL de grupo.
    • Si el usuario no es miembro de un grupo que tiene una ACL explícita de grupo sobre el tema que interesa, pero es miembro de un grupo con ACL explícitas de grupo para un ascendiente del árbol de temas, el ascendiente más cercano tendrá prioridad y el intermediario verificará la operación actual sobre dicha base.
    • Si a un nivel determinado del árbol de temas, el ID de usuario se encuentra en más de un grupo con una ACL explícita, el permiso se otorga si ninguna de las especificaciones es positiva; de lo contrario se deniega.

No se pueden asociar listas de control de acceso (ACL) con temas que incluyan uno o más caracteres comodín. Sin embargo, el acceso desde la aplicación cliente se resuelve correctamente cuando se efectúa el registro de suscripción, incluso si dicha aplicación especifica un carácter comodín en el tema.

Autorizaciones de Grupo público

Además de los grupos definidos por el usuario, WebSphere Message Broker proporciona un grupo implícito, Grupo público, al cual pertenecen automáticamente todos los usuarios. Este grupo implícito simplifica la especificación de ACL en un árbol de temas. En concreto, este grupo se utiliza en la especificación de la ACL correspondiente al tema raíz. Tenga en cuenta que el valor por omisión del tema raíz permite operaciones de publicación y suscripción para el Grupo público. Esta ACL puede visualizarse y modificarse utilizando el entorno de trabajo, pero no puede eliminarse. Determina los permisos por omisión para todo el árbol de temas. Se pueden especificar ACL para el Grupo público en otra parte del árbol de temas, allí donde desee definir permisos para todos los usuarios.

Si tiene un principal llamado Público definido en el entorno de seguridad existente, no puede utilizarlo para la seguridad basada en temas. Si especifica este principal dentro de una ACL, se considera equivalente a Grupo público y, por lo tanto, siempre permite el acceso global.

Autorizaciones mqbrkrs

WebSphere Message Broker otorga privilegios de control de acceso especiales de publicación/suscripción a los miembros del grupo mqbrkrs, y al grupo global Dominio mqbrkrs correspondiente si procede.

Los intermediarios necesitan privilegios especiales para realizar operaciones internas de publicación y suscripción en redes en las que haya control de acceso. Cuando cree un intermediario en una red de este tipo, debe especificar un ID de usuario que pertenezca al grupo mqbrkrs como el ID de usuario de servicio para el intermediario. Al grupo mqbrkrs se le otorgan privilegios implícitos para que sus miembros puedan publicar, suscribirse y solicitar la entrega persistente de mensajes sobre el tema raíz (""). Todos los demás temas heredan estos permisos. Si intenta configurar una ACL para el grupo mqbrkrs utilizando el entorno de trabajo, WebSphere Message Broker hace caso omiso de esta ACL.

ACL y temas del sistema

Los mensajes que se utilizan para operaciones internas de publicación y suscripción se publican en todo el dominio de intermediarios utilizando temas del sistema, que empiezan con las series de caracteres "$SYS" y "$ISYS".

Sólo los miembros del grupo mqbrkrs pueden publicar y suscribirse a estos temas, excepto en los dos casos siguientes:
  1. Si está migrando temas de WebSphere MQ Publicación/Suscripción, puede configurar ACL sobre temas que empiecen por la serie de caracteres "$SYS/STREAM".
  2. Los clientes pueden suscribirse a temas que empiecen por la serie de caracteres "$SYS"; esto significa que las aplicaciones que proporcionan una función de gestión pueden suscribirse al intermediario para sucesos administrativos.

No configure ninguna ACL sobre temas que empiecen por la serie de caracteres "$ISYS". No se le impedirá hacerlo, pero las ACL se ignorarán.

Establecimiento de control de acceso sobre temas

Cualquier usuario que tenga una ACL de seguridad a nivel de objeto que otorgue permiso de pleno control para el objeto de tema raíz, puede definir y manipular las ACL que definen qué principales pueden publicar en y suscribirse a según qué temas. Las ACL también pueden limitar la entrega de mensajes persistentes y definir el nivel de protección de los mensajes.

Todos los principales definidos pueden asociarse a cualquier tema; los permisos que se pueden establecer se indican en la tabla siguiente:
Opción Descripción
Publicación Permite o deniega al principal la publicación de mensajes sobre ese tema.
Suscripción Permite o deniega al principal la suscripción a mensajes sobre ese tema.
Persistente Indica si el principal puede recibir mensajes de forma persistente. Si el principal no tiene esta autorización, todos los mensajes se envían de forma no persistente. Cada suscripción individual indica si el suscriptor requiere mensajes persistentes.
Nivel de calidad de protección (QoP) Indica el nivel de calidad de protección que se aplica. Puede seleccionarse uno de los cuatro valores siguientes:
  • Ninguno
  • Integridad de canal
  • Integridad de mensaje
  • Cifrado
El valor por omisión es 'Ninguno'.
El comportamiento del control de acceso persistente no es idéntico al control de publicación y suscripción:
  • Los clientes a los que se deniega el acceso de publicación se les rechazan sus mensajes de publicación.
  • Los clientes a los que se deniega el acceso de suscripción no reciben la publicación.
  • El control de acceso persistente no deniega el mensaje a los suscriptores, pero deniega su persistencia. Por este motivo, los suscriptores rechazados reciben siempre mensajes, sujetos a su control de acceso de suscripción, pero el mensaje se les envía siempre de forma no persistente, independientemente de la persistencia del mensaje original.

Herencia de las políticas de seguridad

Normalmente, los temas están clasificados en un árbol jerárquico. La ACL de un tema padre puede ser heredada por alguno o todos sus temas descendientes que no tengan una ACL explícita. Por lo tanto, no es necesario tener una ACL explícita asociada a cada uno de los temas. Cada tema tiene una política de ACL que es la de su padre. Si ninguno de los temas padres hasta llegar al tema raíz tiene ACL explícitas, el tema heredará la ACL del tema raíz.

Por ejemplo, en el árbol de temas que se muestra a continuación, el tema raíz no aparece pero se presupone que tiene una ACL para Grupo público cuyos miembros pueden publicar, suscribirse y recibir publicaciones persistentes. (El símbolo "¬" significa "no".)

Herencia de ACL en un árbol de temas


La figura muestra un árbol de temas con la siguiente estructura: A es el nivel superior, con B, K y P en el siguiente nivel. A partir de K, hay más niveles con los nodos M y después N. Para algunos nodos del árbol, se muestran las ACL. El nodo A tiene una ACL de publicación que contiene joe, una ACL de suscripción que contiene Grupo público, y una ACL persistente que contiene ¬Grupo público. El nodo B tiene una ACL de publicación que contiene allen y una ACL de suscripción que contiene HR y ¬Grupo público. No hay ninguna ACL persistente definida explícitamente. El nodo P tiene una ACL de publicación que contiene joe, no tiene ninguna ACL de suscripción definida explícitamente y tiene una ACL persistente que contiene joe. El nodo N tiene una ACL de publicación que contiene mary y joe, una ACL de suscripción que contiene nat y una ACL persistente que contiene Grupo público y ¬nat. Los nodos K y M no tienen ninguna ACL definida explícitamente.
La siguiente tabla muestra las ACL, en algunos casos heredadas, que son el resultado del árbol de temas que aparece en la figura:
Tema Publicadores Suscriptores Persistente
A sólo joe todos ninguno
A/P sólo joe todos sólo joe
A/K sólo joe todos ninguno
A/K/M sólo joe todos ninguno
A/K/M/N sólo mary, joe todos todos excepto nat
A/B allen, joe HR ninguno

Temas creados de forma dinámica

Los temas que no ha creado explícitamente el administrador del sistema sino que se crean dinámicamente cuando un cliente publica o se suscribe a mensajes, se tratan del mismo modo que los creados por el administrador del sistema, aunque no tienen ACL definidas explícitamente. Es decir, que las AC para temas creados dinámicamente se heredan del ascendiente más cercano en el árbol de temas que tenga una política explícita. Por lo tanto, no es necesario definir temas como elementos finales en el árbol si no tienen ACL explícitas.

ACL y temas comodines

Con WebSphere Message Broker no se puede asociar una política de seguridad explícita con un tema comodín. Por ejemplo, no se puede asociar una ACL con el tema "A/+", que representa un jerarquía de dos niveles e incluye "A/B", "A/K" y "A/P".

No obstante, WebSphere Message Broker garantiza una mediación de accesos correcta cuando una aplicación cliente se suscribe a un tema comodín.

Por ejemplo, el tema "A/+" no tiene ni puede tener una política de seguridad explícitamente asociada a él. Por lo tanto, "A/+" hereda su política de "A". Cualquiera puede suscribirse a "A/+" debido a que la ACL de suscripción incluye a todos.

Cuando se publica un mensaje en "A/P" o "A/K", el intermediario lo entrega al usuario que esté suscrito a "A/+". Sin embargo, cuando se publica un mensaje para "A/B", éste sólo se entrega a los suscriptores que están en el grupo HR.

Si el administrador del sistema cambia la ACL de suscripción de cualquier tema que coincida con "A/+", el intermediario aplica correctamente la ACL cuando se entrega el mensaje. La suscripción a un tema comodín tiene la semántica para entregar mensajes sobre todos los temas que coincidan con el comodín, y para los cuales el suscriptor tenga autorización para recibir ese mensaje.

ACL y resolución de suscripciones

El intermediario aplica el control de acceso a través del tema del mensaje que va a entregarse. Los mensajes se entregan solamente a aquellos clientes a los que no se haya denegado el acceso de suscripción, ya sea explícitamente o mediante una herencia. Puesto que una suscripción puede contener un carácter comodín, la coincidencia real con el espacio de nombres del tema y, por lo tanto con las ACL del tema, no se puede realizar cuando se recibe la suscripción. La decisión de entregar un mensaje a un suscriptor sólo se toma cuando el intermediario de mensajes está procesando un mensaje específico con un tema.

Activación de actualizaciones de ACL de temas

Las actualizaciones en la ACL de un tema no se activan hasta que se despliegan y se activan a través del dominio de intermediarios desde el entorno de trabajo de WebSphere Message Broker.

Debe tener una ACL de seguridad a nivel de objeto que proporcione permiso de pleno control para el objeto de tema raíz.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
aq01203_