Escenario de ejemplo

CA AppLogic no proporciona un esquema extenso de grupos y usuarios predefinidos. Esto permite que los administradores del grid puedan configurar los usuarios y grupos y el acceso a los objetos de acuerdo con las necesidades de cada situación particular. En general, los administradores de grid siguen estos pasos:

• Crear usuarios locales.
• Crear conjuntos de grupos locales. Estos grupos se pueden utilizar para segregar usuarios según el tipo de trabajo (por ejemplo, administración del grid, desarrollo de aplicaciones, control de calidad, etc.), estructuras de negocio (por ejemplo, por departamento o unidad de negocio, de modo que cada grupo de usuarios pueda compartir un grid para el trabajo de desarrollo) o bien otras divisiones que puedan resultar prácticas. Se puede cumplir el mismo objetivo mediante grupos globales, lo cual es particularmente útil cuando se utiliza la misma configuración para dos o más grids.
• Agregar usuarios a grupos, o grupos a grupos, según sea necesario.
• Modificar las listas de control de acceso de los objetos para asignar a los grupos derechos de nivel de acceso específicos.

El siguiente escenario ofrece un ejemplo práctico que muestra cómo se puede utilizar este proceso para controlar de forma efectiva el acceso de los usuarios.

Ace Starships Incorporated (ASI) se dedica a la construcción de aeronaves espaciales. Cada una de las naves utiliza sistemas de software para controlar, entre otros propósitos, el soporte vital y la propulsión. Estos dos sistemas de software se han desarrollado en un gran grid compartido de CA AppLogic antes de que se realizara su implementación en los grids de producción de las naves espaciales. El proceso de desarrollo en este grid incluye los siguientes colectivos:

• Equipo de desarrollo del soporte vital
• Equipo de desarrollo de la propulsión
• Personal externo: especialistas en el desarrollo de dispositivos de middleware (dispositivos comunes)
• Auditores: personal de ASI que necesita disponer de acceso no destructivo a desarrollo
• Control de calidad (QA): personal dedicado al control de calidad dedicado a probar los productos creados por los equipos de desarrollo y el personal externo

Existe también:

• Un usuario global cuyo nombre es john_adams, administrador del grid (se encarga de las tareas de administración del grid)
• Un usuario global cuyo nombre es jane_osprey, operadora del grid (es la persona responsable del grid mientras el administrador no está de servicio)

Además:

• ASI emplea un servicio de directorio basado en LDAP para gestionar los usuarios y los grupos de forma centralizada para toda la compañía. Todos, excepto el personal externo, disponen de una cuenta para este sistema.
• El equipo de propulsión utiliza varias aplicaciones creadas por el equipo de soporte vital, pero no modifica la arquitectura de estas aplicaciones.
• Los dos equipos utilizan dispositivos desarrollados por el personal externo, pero no modifican estos dispositivos.
• Hay catálogos globales que contienen dispositivos específicos para cada uno de los esfuerzos de desarrollo: life_support (soporte vital), propulsion (propulsión) y outsiders (equipo externo).

Una de las primeras decisiones que se deben tomar en este escenario es si la pertenencia a los grupos se gestionará a través del directorio que abarca toda la compañía o si se gestionará a través de grupos locales. Para este ejemplo, seguiremos el primer planteamiento:

• A través de este directorio de ASI se crean los grupos life_support, propulsion, QA y auditors, y se incluyen en estos grupos los correspondientes usuarios globales. Esta operación se realiza fuera de CA AppLogic.

Siguiendo con el ejemplo, el usuario inicial de CA AppLogic, que es un miembro del grupo local admin, establece la siguiente disposición de usuarios y grupos:

• Crea una cuenta de usuario local para cada uno de los empleados externos.
• Crea los siguientes grupos:
  • outsiders
  • grid_operators
  • app_developers
• Establece la pertenencia a los grupos:
  • Agrega los usuarios locales recién creados al grupo local outsiders.
  • Agrega los grupos globales life_support, propulsion y QA al grupo app_developers.
  • Agrega el grupo local outsiders al grupo app_developers.
  • Agrega el usuario global john_adams al grupo admin
  • Agrega el usuario global jane_osprey al grupo grid_operators
• Modifica las listas de control de objetos para configurar el acceso para los objetos:
  • Modifica la lista de control de acceso del grid para:
    • Proporcionar derechos de nivel de acceso grid_operator al grupo local grid_operators.
    • Proporcionar derechos de nivel de acceso app_developer al grupo local app_developers.
    • Proporcionar derechos de nivel de acceso al grupo global auditors.
  • Modifica las listas de control de acceso de los catálogos globales para:
    • Proporcionar al grupo global life_support derechos de nivel de acceso full en el catálogo life_support; proporcionar al grupo global propulsion derechos de nivel de acceso full en el catálogo propulsion; proporcionar al grupo local outsiders derechos de nivel de acceso full en el catálogo outsiders.
    • Proporcionar al grupo local app_developers derechos de nivel de acceso configure en el catálogo outsiders; proporcionar al grupo global propulsion derechos de nivel de acceso configure en el catálogo life_support.

Las siguientes tablas muestran la pertenencia a grupos de este escenario:

La siguiente tabla muestra los derechos de nivel de acceso concedidos en este escenario a los elementos principales para los objetos oportunos:

Se ha completado la configuración inicial de usuarios y grupos. Llegados a este punto, todos los usuarios globales que pertenecen a los grupos globales life_support, propulsion, QA y auditors ya pueden iniciar sesión en el grid y cada usuario obtiene de forma automática los derechos de nivel de acceso necesarios para realizar su trabajo.

También se ha configurado el acceso a los catálogos globales a fin de que los dispositivos resulten accesibles, tal y como es necesario. Sin embargo, dentro de cada catálogo sólo podrán realizar operaciones de destrucción los miembros del grupo que dispone de derechos de nivel de acceso full para el catálogo correspondiente.

Cuando un usuario crea una nueva aplicación, el usuario pasa a ser el propietario de la aplicación y dispone de derechos de nivel de acceso full en la aplicación. Es posible que en algún momento el usuario desee modificar la lista de control de acceso de la aplicación para dar a otros miembros de su equipo de desarrollo, o de otro equipo, acceso a la aplicación. Por ejemplo:

• Un miembro del equipo de soporte vital puede conceder derechos de nivel de acceso full al grupo local life_support en la aplicación para que otros miembros del equipo la puedan modificar.
• Un miembro del equipo de soporte vital puede conceder al grupo local propulsion derechos de nivel de acceso configure en la aplicación para que los miembros de este grupo puedan configurar o utilizar la aplicación, pero no modificar su arquitectura.
• Un miembro del equipo de soporte vital puede conceder al grupo global QA los derechos de nivel de acceso que considere necesarios para realizar pruebas en la aplicación (por ejemplo, acceso read para hacer una copia de la aplicación para hacer pruebas de forma independiente, acceso configure para configurar o utilizar la aplicación sin modificar su arquitectura, etc.).