Las entradas de la lista de control de acceso (ACL)
permiten o deniegan el acceso de un usuario a recursos de ejecución específicos. Los recursos de tiempo de ejecución son objetos de
WebSphere Message Broker que existen durante la
ejecución en el dominio de intermediarios.
Cada objeto de tiempo de
ejecución tiene una lista de control de acceso (ACL) que determina qué
usuarios y grupos pueden acceder al objeto. Mediante las entradas ACL, puede controlar el acceso de los usuarios a
objetos específicos del dominio de intermediarios y permite a un usuario o grupo ver, modificar o desplegar el objeto. Puede manipular las entradas ACL utilizando la API entorno de trabajo, la API Proxy del
Gestor de configuración de Java o los mandatos
mqsicreateaclentry, mqsideleteaclentry y mqsilistaclentry.
Por ejemplo, el usuario
USER1 puede tener acceso para modificar BROKERA, pero no tener
derechos de acceso a BROKERB. En otro ejemplo, el mismo usuario puede
tener acceso para desplegar al grupo de ejecución EXEGRP1, pero no a
EXEGRP2, aunque ambos sean miembros de BROKERA.
Gestor de configuración comprueba la tabla ACL
y si su ID de usuario está incluido en la entrada ACL del
objeto nombrado, tiene autorización para realizar la operación.
Hay cuatro niveles de acceso diferentes que se pueden conceder a un usuario o grupo: Control total, Ver, Desplegar y Editar. No todos los niveles de acceso son válidos para todos los tipos de objetos. Consulte Permisos de ACL para ver 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.
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 de intermediarios pero no confíe en las entradas ACL para proteger los dominios de intermediarios. Utilice SSL o salidas de seguridad para proteger los canales entre los componentes del dominio de intermediarios. Aunque las ACL permiten o deniegan el acceso de un usuario a un objeto según el ID de usuario, no protegen el objeto ya que una entrada ACL no puede verificar la identidad del usuario.
Para reducir el número de entradas ACL 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 otorga permiso a dicho objeto y a todos los objetos que hay debajo del mismo en la jerarquía, a menos que se altere temporalmente especificando otra entrada ACL. El diagrama siguiente muestra una jerarquía de ejemplo de las entradas de la lista de control de acceso:
-Para ver ejemplos que muestran cómo está jerarquía funciona en la práctica, consulte Configuración de la seguridad para los componentes del dominio.
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 para 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 otorgando un permiso que esté en un lugar inferior del árbol. Esto es necesario porque, de lo contrario, un usuario podría otorgarse a sí mismo una entrada de vista y después no podría suprimirla.
En z/OS, debe definir un segmento OMVS para los ID de usuario y grupos para que un Gestor de configuración pueda obtener la información de ID de usuario y grupo de la base de datos ESM (External Security Manager).
En versiones anteriores de WebSphere Message Broker, el acceso a los objetos de tiempo de ejecución se controlaba definiendo un conjunto de grupos y asignando usuarios a dichos grupos. Las entradas ACL permiten controlar el acceso con más granularidad que los grupos. Las entradas ACL también permiten que un solo Gestor de configuración gestione los sistemas de desarrollo, prueba y producción por separado, configurando el acceso de los usuarios a cada intermediario. Si utilizara grupos, tendría que colocar los sistemas de desarrollo, prueba y producción en dominios de intermediarios separados, cada uno de ellos controlado por un Gestor de configuración individual.
Cuando utilice las ACL de usuario individuales, debe definir los usuarios en la estación de trabajo que está accediendo a los objetos (es decir, la máquina en la que se ejecuta el kit de utilidades), pero no necesita definirlas en la estación de trabajo que ejecuta el Gestor de configuración. Sin embargo, cuando esté utilizando las ACL de grupo, debe definir los usuarios en ambas estaciones de trabajo y, a continuación, definir los grupos en la estación de trabajo que ejecuta el Gestor de configuración, antes de añadir los usuarios a los grupos. Esto es necesario porque no se pasa información de grupo entre las estaciones de trabajo.