RBAC es el sistema de control de acceso basado en roles de CA AppLogic®. RBAC proporciona un control granular sobre qué usuarios pueden realizar acciones específicas en objetos determinados en un grid. La finalidad general de RBAC es permitir que varios usuarios trabajen en un solo grid sin entorpecer el trabajo de los demás. RBAC no está diseñado para proporcionar la funcionalidad de acceso multicliente. Por ejemplo, todos los usuarios pueden consultar la lista de todas las aplicaciones, de forma similar a como sucede en Linux, donde los usuarios pueden enumerar los archivos a los cuales no tienen acceso (no se segregan los espacios de nombres del objeto).
RBAC es compatible con los usuarios y grupos para autorizar una acción de usuario. Los grupos pueden incluir usuarios u otros grupos como miembros. Se pueden crear usuarios y grupos que sean específicos de un grid determinado mediante la interfaz de línea de comandos (CLI) de CA AppLogic®. La información de usuario y de grupo se mantiene en un servicio de directorio que se incluye en el controlador del grid.
RBAC es compatible con el uso opcional de un servicio de directorio externo como Active Directory de Microsoft® Windows®. En este caso, la información de usuario y grupo se obtiene del servicio de directorio externo cuando un usuario se autentica mediante este servicio.
CA AppLogic® utiliza el término locales para referirse a los usuarios y grupos que son específicos de un grid. Los usuarios y grupos que se mantienen en un servicio de directorio externo se consideran globales. Los respectivos servicios de directorio se distinguen también como locales o globales. Se pueden configurar el grid de modo que sólo utilice usuarios y grupos locales, o bien que utilice tanto usuarios y grupos locales como globales.
A los usuarios y los grupos también se les puede llamar elementos principales. Para identificar de forma única los elementos principales, se asigna a cada uno de ellos un identificador único, o ID de elemento principal. Si el elemento principal es un usuario, el ID principal suele denominarse con el ID de usuario. Del mismo modo, si el elemento principal es un grupo, el ID principal suele denominarse con el ID de grupo. Se puede utilizar el ID del elemento principal para buscar el ámbito, el tipo y el nombre del elemento principal. El ámbito del elemento principal indica si este es local o global. El tipo del elemento principal indica si este es un usuario o grupo. El nombre del elemento principal es un nombre común que resulte fácil de utilizar para los usuarios. Por ejemplo, el usuario local John es un elemento principal con alcance local, del tipo usuario y con el nombre John.
La función principal de RBAC es encargarse de la autorización de usuario. Para proporcionar esta autorización, RBAC utiliza listas de control de acceso (ACL). Hay tres tipos de objeto de grid que tienen asociada una lista de control de acceso: las aplicaciones, los catálogos globales y el grid propiamente dicho. Las ACL están formadas por un propietario y una lista de entradas. El propietario es un elemento principal y tiene el derecho implícito de modificación de la lista de control de acceso. Cada entrada está compuesta por un elemento principal y el nivel de acceso correspondiente que determina el tipo de autorización que tiene el elemento principal para realizar acciones sobre el objeto. Los niveles de acceso son recopilaciones de permisos a las cuales se da nombre. Por ejemplo, el objeto del grid tiene un nivel de acceso con el nombre grid_administrator, y uno de los permisos incluidos en este nivel de acceso es el permiso para iniciar sesión en el grid. Un ID principal único representa cada elemento principal en una ACL.
RBAC no elimina el acceso del encargado del mantenimiento en el grid. Las operaciones realizadas por los encargados del mantenimiento no están sujetas a autorización.
Una ACL es una lista de todas las formas de acceso que se otorgan a un objeto. Esta lista incluye niveles de permiso para individuos y grupos. Un usuario se puede incluir como un individuo y como un miembro de uno o varios de los grupos enumerados. Por lo tanto, el sistema evalúa cada entrada relevante de la ACL al tiempo que otorga acceso al objeto. El sistema concede al usuario el acceso más permisivo al que pueden optar por ser miembros de un grupo o un individuo incluido en la lista. Si dicho "acceso más permisivo" proporciona el permiso necesario en el objeto, la comprobación de autorización se realiza correctamente.
El sistema considera la pertenencia al grupo de forma recursiva. De este modo, el sistema considera que un usuario es miembro de un grupo en dos casos.
La pertenencia recursiva a grupos se extiende a tantos niveles de grupos anidados en otros grupos como se definan.
Ejemplo: un usuario con acceso de grupo e individual en una ACL de grid
José es un miembro del grupo financial_operators en la ACL del grid. A este grupo se le ha asignado el nivel de acceso grid_user en el objeto del grid. Este nivel de acceso incluye permisos para aprovisionar aplicaciones. Este nivel de acceso no incluye permisos para crear un usuario local.
José también tiene una entrada individual en la ACL del grid. A esta entrada individual se le ha asignado el nivel de acceso grid_administrator en el objeto del grid. Este nivel de acceso incluye permisos para crear un usuario local. Este nivel de acceso no incluye permisos para aprovisionar aplicaciones.
José se conecta al grid. En la misma sesión, José desea crear un usuario local y aprovisionar una aplicación. La comprobación de autorización permite a José realizar ambas acciones. La pertenencia al grupo permite a José aprovisionar una aplicación. Por su parte, su entrada individual en la ACL le permite crear un usuario local.
Ejemplo: pertenencia recursiva grupos
Cristina desea suprimir un usuario local del grid. Únicamente los miembros del grupo grid_administrators pueden suprimir usuarios locales. Cristina no aparece como miembro del grupo grid_administrators. Sin embargo, Cristina pertenece al grupo al_senior_admins. Este grupo se incluye como miembro del grupo grid_administrators. Por lo tanto, el sistema considera que Cristina es un miembro del grupo grid_administrators. Cristina cuenta con permisos de supresión de usuarios locales.
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|