Las entras ACL (Lista de control de acceso) conceden o deniegan el acceso de un usuario a un objeto. No obstante, las entradas ACL no protegen el objeto debido a que la entrada ACL no puede verificar la identidad del usuario. Una entrada ACL contiene el nombre de usuario y puede especificar un nombre de host o un nombre de dominio. Por ejemplo, un usuario puede obtener acceso a los objetos creando una cuenta en un sistema que tenga un nombre de host igual al de un nombre de dominio Windows autorizado. Utilice las entradas ACL para controlar el acceso a los objetos del dominio del intermediario pero no confíe en las entradas ACL para proteger los dominios del intermediario. Utilice SSL o las salidas de seguridad para proteger los canales entre los componentes del dominio del intermediario.
WebSphere Message Broker utiliza las entradas ACL para controlar los usuarios y grupos que pueden manipular objetos en el dominio del intermediario. Hay cuatro niveles de acceso diferentes que se pueden conceder a un usuario o grupo: Total, Vista, Desplegar y Editar. No todos los niveles de acceso son válidos para todos los tipos de objetos. Consulte Permisos de ACL para obtener una lista de los permisos que se pueden aplicar a cada tipo de objeto y un resumen de las acciones que el usuario o grupo puede realizar.
Para reducir el número de entradas de control de accesos que un administrador de intermediario debe crear, los permisos de ACL se comportan de un modo jerárquico. La raíz del árbol es el objeto ConfigManangerProxy que tiene tres hijos: RootTopic, Subscriptions y PubSubTopology. El objeto PubSubTopology tiene cero o más intermediarios como hijos y cada intermediario puede tener cero o más grupos de ejecución como hijos. Cuando se añade un entrada ACL a un objeto determinado, se concede a dicho objeto y a todos los objetos que hay debajo del mismo en la jerarquía, a menos que esté alterada temporalmente por otra entrada ACL.
En z/OS, debe definir un segmento OMVS para los ID de usuario y de grupo, para que un Gestor de configuración pueda obtener información de ID de usuario y de grupo de la base de datos ESM (External Security Manager).
El diagrama siguiente muestra una jerarquía de ejemplo:
Los ejemplos siguientes muestran como funciona este comportamiento jerárquico en la práctica.
Ejemplo 1
El UsuarioA no tiene entradas de control de acceso. Por consiguiente, el UsuarioA no puede manipular ningún objeto de la jerarquía ni ver ninguno de los objetos definidos en la jerarquía.
Ejemplo 2
El UsuarioB tiene una entrada ACL que le proporciona autorización de despliegue para el grupo de ejecución Eg1A. Esto le proporciona la autorización de vista implícita para PubSubTopology e Intemediario1. El UsuarioB debe poder ver PubSubTopology e Intermediario1, por ejemplo, en el Kit de herramientas de Message Brokers, para poder desplegar Eg1A.
Dado que el UsuarioB no tiene entradas ACL para PubSubTopology o Intermediario1, el UsuarioB no hereda el acceso a otro intermediario o grupos de ejecución de la jerarquía. En la práctica, esto significa que el UsuarioB puede ver que hay otro grupo de ejecución definido en el Intermediario1 pero no puede ver los detalles (incluido el nombre del grupo de ejecución). De forma similar, el UsuarioB puede ver que existe otro intermediario en la topología, pero no puede ver ningún detalle. El UsuarioB no tiene acceso a RootTopic o Subscriptions (la tabla de suscripciones).
mmqsicreateaclentry testcm -u UsuarioB -a -x D -b Intermediario1 -e Eg1AEl mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userb -USER - D - Intermediario1/Eg1A - ExecutionGroup
Ejemplo 3
CMP Ver
RootTopic Ver
Subs Ver
Topology Ver
Intermediario1 Total
Eg1A Total
Eg1B Total
Intermediario2 Ver
Eg2A Ver
Eg2B Ver
mqsicreateaclentry testcm -u UsuarioC -a -x V -p mqsicreateaclentry testcm -u UsuarioC -a -x F -b Intermediario1El mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userc - USER - V - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userc - USER - F - Intermediario1 - Broker
Ejemplo 4
CMP Total
RootTopic Total
Subs Total
Topology Total
Intermediario1 Ver
Eg1A Ver
Eg1B Ver
Intermediario2 Total
Eg2A Total
Eg2B Total
mqsicreateaclentry testcm -u UsuarioD -a -x F -p mqsicreateaclentry testcm -u UsuarioD -a -x V -b Intermediario1El mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userd - USER - F - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userd - USER - V - Intermediario1 - BrokerA continuación, el mandato siguiente puede suprimir las entradas ACL para el UsuarioD:
mqsideleteaclentry testcm -u UsuarioD -a -b Intermediario1
Para cambiar las entradas de control de acceso para un objeto, un usuario debe tener autorización total para dicho objeto o cualquier padre de la jerarquía. Esto significa que el permiso de cambiar las ACL propiamente dichas funciona del mismo modo que se ha descrito anteriormente, con la excepción que el acceso a las ACL no se puede suprimir concediendo un permiso que esté en un lugar inferior del árbol. Esto es necesario debido a que, de lo contrario, un usuario podría concederse a sí mismo una entrada de vista y después no podría suprimirla.
Las entradas ACL se pueden manipular utilizando la API Java de Proxy del Gestor de configuración o utilizando los mandatos mqsicreateaclentry, mqsideleteaclentry y mqsilistaclentry.