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 y a qué temas.

Para cada tema al que desee restringir el acceso puede especificar los principales (ID de usuarios y grupos de ID de usuarios) que pueden publicar y los principales que pueden suscribirse a dicho tema. También puede especificar qué principales pueden solicitar la entrega permanente de mensajes.

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

La seguridad basada en temas se gestiona mediante un Servidor de nombres de usuarios que utiliza las listas de control de accesos (ACL) que el usuario crea para decidir las autorizaciones que se aplican.

Principales y el servidor de nombres de usuarios

El Servidor de nombres de usuarios de WebSphere Business Integration Message Broker gestiona el conjunto de principales que ya están definidos 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 usuarios se da a conocer al intermediario y al Gestor de configuración especificando el gestor de colas del Servidor de nombres de usuarios en los mandatos mqsicreatebroker y mqsicreateconfigmgr.

Los intermediarios de mensajes que están dentro del dominio de intermediarios interactúan con el Servidor de nombres de usuarios para recuperar el conjunto completo de usuarios y grupos a partir del cual se crean las listas de control de accesos y con las que se validan las peticiones de publicación/suscripción. El Gestor de configuración interactúa con el Servidor de nombres de usuarios para visualizar los usuarios y grupos de usuarios en las ACL creadas utilizando el Editor de jerarquía de temas que proporciona la perspectiva Administración de intermediarios del área de trabajo.

Listas de control de accesos

Las listas de control de accesos se utilizan para definir, para cualquier tema y principal, el derecho de dicho principal a publicar sobre un tema o a suscribirse a dicho tema, o a solicitar la entrega permanente de una publicación sobre dicho tema.

Las ACL también pueden utilizarse para definir el nivel de protección de mensajes que se desea aplicar a cada tema.

Especifique estas definiciones utilizando el Editor de jerarquía de temas en el perspectiva Administración de intermediarios del área de trabajo.

El control de accesos puede establecerse explícitamente para cada tema. No obstante, si no se define ninguna ACL explícita para un tema, el control de accesos se adopta de un tema anterior o superior, según lo definido por la estructura jerárquica del árbol de temas. Si ningún temas de la jerarquía hasta llegar al tema raíz tiene una ACL explícita, el tema adoptará la ACL del tema raíz.

Cualquier principal que el Servidor de nombres de usuarios conozca puede asociarse con un tema de esta forma.

Resolución de discrepancias en las ACL

Si los principales del dominio de intermediarios incluyen uno o más usuarios en más de un grupo, los valores explícitos o adoptados de las ACL pueden discrepar. Las siguientes normas explican las normas con las que se resuelve una discrepancia:
  • Si el usuario tiene una ACL de usuario explícita sobre el tema que interesa, ésta tendrá siempre prioridad y el intermediario verificará la operación actual sobre esta base.
  • Si el usuario no tiene una ACL de usuario explícita sobre el tema que interesa, pero tiene ACL explícitas de usuario para un tema anterior en el árbol de temas, la ACL anterior de ese usuario que esté más cerca tendrá prioridad y el intermediario verificará la operación actual sobre esa base.
  • Si no hay ACL explícitas de usuario para el usuario sobre el tema que interesa o sobre los temas anteriores, el intermediario intentará verificar la operación actual sobre la base de las ACL de grupo:
    • Si el usuario es miembro de un grupo que tiene una ACL de grupo explícita sobre el tema que interesa, el intermediario verificará la operación actual sobre la base de esta ACL de grupo.
    • Si el usuario no es miembro de un grupo que tiene una ACL de grupo explícita sobre el tema que interesa, pero es miembro de un grupo con ACL de grupo explícitas de un tema anterior del árbol de temas, la ACL anterior de ese grupo que esté más cerca tendrá prioridad y el intermediario verificará la operación actual sobre esta base.
    • Si a un nivel particular del árbol de temas, el ID de usuario está contenido en más de un grupo con una ACL explícita, el permiso se otorgará si ninguna de las especificaciones es positiva; de lo contrario se denegara.

Las ACL no se pueden asociar a temas que contengan uno o más comodines. Sin embargo, el acceso desde la aplicación cliente se resuelve correctamente cuando se realiza el registro de suscripción, incluso si la aplicación especifica un comodín en el tema.

Autorizaciones de PublicGroup

Además de los grupos que define el usuario, WebSphere Business Integration Message Broker proporciona un grupo implícito, PublicGroup, al que pertenecen automáticamente todos los usuarios. Este grupo implícito simplifica la especificación de las ACL en un árbol de temas. Particularmente, este grupo se utiliza en la especificación de la ACL para el tema raíz. Tenga en cuenta que el valor por omisión del tema raíz permite publicar y suscribir operaciones para PublicGroup. Puede ver y cambiar esta ACL utilizando el área de trabajo, pero no podrá eliminarla. Determina los permisos por omisión para todo el árbol de temas. Puede especificar ACL para el PublicGroup en otro lugar del árbol de temas, dondequiera que desee definir permisos para todos los usuarios.

Si tiene un principal llamado Public definido en el entorno de seguridad existente, no podrá utilizarlo para la seguridad basada en temas. Si especifica este valor dentro de una ACL, se igualará a PublicGroup y, por lo tanto, permitirá siempre un acceso global.

Autorizaciones mqbrkrs

WebSphere Business Integration Message Broker otorga privilegios especiales de control de accesos de publicación/suscripción a miembros del grupo mqbrkrs y al grupo global mqbrkrs del dominio, si corresponde.

Los intermediarios necesitan privilegios especiales para realizar operaciones internas de publicación y suscripción en redes en las que hay control de accesos. Cuando se crea un intermediario en una red de este tipo, ha de especificarse un ID de usuario que pertenezca al grupo mqbrkrs como ID de usuario de servicio para el intermediario. El grupo mqbrkrs obtiene privilegios implícitos de forma que sus miembros puedan publicar, suscribir y solicitar la entrega permanente de mensajes sobre el tema raíz (""). Los demás temas adoptan estos permisos. Si intenta configurar una ACL para el grupo mqbrkrs utilizando el área de trabajo, WebSphere Business Integration Message Broker ignorará dicha ACL.

ACL y temas del sistema

Los mensajes que se utilizan para operaciones de publicación y suscripción internas se publican a través del dominio de intermediarios utilizando temas del sistema, que empiezan por las series de caracteres "$SYS" y "$ISYS". Estos temas han de publicarse y suscribirse para que sean únicamente miembros de mqbrkrs, con la excepción de los dos casos siguientes:
  1. Si está migrando temas desde MQSeries Publicación/suscripción, puede configurar las 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 un función de gestión pueden suscribirse al intermediario para sucesos administrativos.

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

Establecimiento del control de accesos sobre temas

Todos los miembros del grupo mqbrtpic pueden definir y manipular las ACL que definen los principales que pueden publicar determinados temas y suscribirse a ellos. Las ACL también pueden limitar la entrega de mensajes permanente y definir el nivel de protección de mensajes. Todos los principales definidos pueden asociarse a cualquier tema; los permisos que pueden establecerse aparecen en la siguiente tabla:
Opción Descripción
Publicar Permite o deniega al principal la publicación de mensajes sobre este tema.
Suscribir Permite o deniega al principal la suscripción a mensajes sobre este tema.
Permanente Especifica si el principal puede recibir mensajes permanentemente. Si el principal no tiene permiso, todos los mensajes se envían de forma no permanente. Cada suscripción individual indica si el suscriptor requiere mensajes permanentes.
Nivel de calidad de protección (QoP) Indica el nivel de protección de mensajes que se aplica. Puede elegirse uno de los cuatro valores siguientes:
  • Ninguno
  • Integridad del canal
  • Integridad del mensaje
  • Cifrado
El valor por omisión es 'Ninguno'.
El funcionamiento del control de accesos permanente no es idéntico al control de publicación y suscripción:
  • A 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 accesos permanente no deniega el mensaje a los suscriptores, pero deniega su permanencia, por lo tanto, los suscriptores rechazados, reciben siempre los mensajes, sujetos a su control de accesos de suscripción, pero reciben siempre los mensajes que se les envían de forma no permanente, independientemente de la permanencia del mensaje original.

Adopción de políticas de seguridad

Normalmente, los temas están ordenados en un árbol jerárquico. La ACL de un tema superior puede ser adoptada por alguno o todos los temas inferiores que no tienen una ACL explícita. Por lo tanto, no es necesario tener una ACL explícita asociada a cada uno de temas. Todos los temas tienen una política de ACL que es la del tema superior. Si ninguno de los temas superiores, hasta llegar al tema raíz, tiene ACL explícitas, el tema adopta la ACL del tema raíz.

Por ejemplo, en el árbol de temas que aparece abajo, el tema raíz no puede verse, pero se presupone que tiene una ACL para PublicGroup cuyos miembros pueden publicar, suscribir y recibir publicaciones permanentes.(El símbolo "¬" significa "no".)

Adopción de ACL en un árbol de temas


La figura muestra un árbol de temas con la siguiente estructura. A es el nivel superior, y B, K y P son el siguiente nivel.  Hay más niveles que parten de K con los nodos M y, a continuación, N. En algunos de los nodos del árbol, las ACL pueden verse. El nodo A tiene una ACL de publicación que contiene joe, una ACL de suscripción que contiene Public Group y una ACL de permanencia que contiene ¬Public Group. El nodo B tiene una ACL de publicación que contiene allen, y una ACL de suscripción que contiene HR y ¬Public Group. No hay ninguna ACL de permanencia definida. El nodo P tiene una ACL de publicación que contiene joe, ninguna ACL de suscripción definida explícitamente y una ACL permanente 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 permanente que contiene Public Group y ¬nat. Los nodos K y M no tienen ACL definidas explícitamente.
La siguiente tabla muestra las ACL, adoptadas en algunos casos, que son el resultado del árbol de temas que aparece en la figura:
Tema Publicadores Suscriptores Permanente
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 dinámicamente

Los temas que no se crea explícitamente el administrador del sistema, pero que se crean dinámicamente cuando un cliente publica mensajes o se suscribe a ellos, se tratan del mismo modo que los creados por el administrador del sistema, pero no tienen ACL definidas explícitamente. Es decir, que las ACL para temas creados dinámicamente proceden del tema anterior más cercano en el árbol de temas que tiene una política explícita. Por lo tanto, no es necesario definir temas secundarios en el árbol, si no tienen ACL explícitas.

ACL y temas comodines

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

Así mismo, WebSphere Business Integration Message Broker no garantiza una mediación de acceso 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 asociada a él. Por lo tanto, "A/+" adopta su política de "A". Cualquier usuario puede suscribirse a "A/+" puesto que la ACL de suscripción incluye a todo el mundo.

Cuando se publica un mensaje sobre "A/P" o "A/K", el intermediario lo entrega al usuario que se haya inscrito para "A/+". No obstante, cuando un mensaje se publica para "A/B", sólo se entrega a suscriptores que están en el grupo HR.

Si el administrador del sistema cambia la ACL de suscripción de un tema que coincida con "A/+", el intermediario impondrá correctamente la ACL cuando se entregue 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 que el suscriptor tenga autorización para recibir el mensaje.

ACL y resolución de suscripciones

El intermediario impone el control de accesos a través del tema del mensaje que va a entregarse. Los mensajes sólo se entregan a los clientes a los que no se ha denegado el acceso de suscripción a ese tema, ya sea explícitamente o porque se ha adoptado. Como una suscripción puede contener un comodín, la coincidencia real con el espacio de nombres del tema y, por lo tanto, las ACL del tema, no puede efectuarse cuando se recibe la suscripción. La decisión de entregar un mensaje a un suscriptor se realiza únicamente cuando un mensaje específico con un tema está siendo procesado por el intermediario de mensajes.

Activación de las actualizaciones de ACL de temas

La actualizaciones a una ACL de un tema no entran en vigor hasta que se difunden y activan a través del dominio de intermediarios a partir del área de trabajo de WebSphere Business Integration Message Broker. Es necesario ser miembro del grupo mqbrops para difundir ACL, o un usuario o miembro de un grupo que tenga una ACL de seguridad a nivel de objetos que proporcione, como mínimo, permiso de difusión para el objeto del tema raíz.

Conceptos relacionados
Servidor de nombres de usuarios
Temas
Publicadores
Suscriptores
Seguridad
Seguridad para recursos de ejecución
Seguridad de publicación/suscripción

Tareas relacionadas
Habilitación de la seguridad basada en temas
Creación de un Servidor de nombres de usuarios
Creación de entradas ACL

Referencia relacionada
Editor de jerarquías de temas
Editor de consulta de suscripciones