1.3 Descripción arquitectónica de alto nivel
La aplicación de usuario del Gestor de identidades se basa en una serie de componentes independientes que interactúan. En la tabla siguiente se describen los componentes básicos, así como sus responsabilidades fundamentales.
En términos de flujo de la información, los componentes mencionados anteriormente están vinculados entre sí lógicamente tal como se muestra en el esquema siguiente. Desde un punto de vista físico, los componentes individuales pueden estar ubicados (y así ocurrirá en muchos casos) en más de una máquina. Por ejemplo, aunque el repositorio seguro de identidades (y su principal herramienta de administración, iManager) se encuentren en la máquina que alberga el motor del Gestor de identidades, JBoss (y la aplicación de usuario), normalmente, estarán en otra máquina (o grupo de máquinas, si se agrupan en clúster). Asimismo, por motivos no sólo de rendimiento, sino también de seguridad y de recuperación tras fallos, la base de datos (MySQL) estará en su propia máquina.
1.3.1 Repositorio seguro de identidades
El repositorio seguro de identidades se utiliza para almacenar datos de identidades y definiciones de nivel de abstracción de diversos tipos. Con este fin, se utiliza una instancia de eDirectory (que se ejecuta en Windows, Solaris o Linux). Mediante eDirectory, el Gestor de identidades puede aprovechar el directorio LDAPv3 corporativo, ampliable masivamente y de eficacia demostrada con funciones de partición y réplica, más una herramienta de configuración y gestión flexible basada en Web (iManager) que ofrece un punto de integración administrativa todo en uno entre el Gestor de identidades y el mismo eDirectory.
1.3.2 JBoss
La aplicación de usuario está empaquetada como un archivo de la aplicación Web Java o un archivo WAR. El archivo WAR se implanta en JBoss, el conocido servidor de aplicación Java de código abierto (que utiliza Tomcat como motor servlet; no se muestra en el esquema). El uso de JBoss como entorno de ejecución aporta un gran número de ventajas, incluidas las siguientes:
- El código fuente está disponible gratuitamente.
- A partir de la versión 4.0.3, JBoss puede agruparse en clúster.
- JBoss es totalmente compatible con J2EE, lo que significa que cualquier aplicación J2EE puede ejecutarse en él. Se pueden albergar aplicaciones adicionales (por ejemplo, Servicios Web) en la misma instancia de JBoss en la que se ejecutan las aplicaciones del usuario.
- JBoss admite los servicios de autorización y seguridad JACC y JAAS estándar de Java ( en los que se basa la aplicación de usuario para el acceso al repositorio seguro de identidades).
- JBoss se ejecuta en varias plataformas diferentes, entre las que figuran las conocidas versiones de Windows y Linux.
El archivo WAR de la aplicación de usuario contiene código ejecutable para la aplicación de usuario que, a su vez, se genera utilizando una arquitectura MVC (Modelo-Vista-Controlador), para separar temas. Las interfaces de usuario se ejecutan como portlets modulares dentro de la aplicación de usuario. Existen diferentes portlets para ver organigramas corporativos, realizar búsquedas, ver detalles del usuario, restaurar contraseñas, etc.
Para obtener más información acerca de los diversos aspectos de la implantación de aplicaciones Web en JBoss, consulte la documentación de JBoss en http://www.jboss.org/products/jbossas/docs.
1.3.3 Base de datos
La aplicación de usuario se basa en una base de datos (por defecto, MySQL; consulte la guía de instalación para ver una lista de las bases de datos admitidas) para almacenar varios tipos de información.
- Datos de la configuración de la aplicación de usuario: por ejemplo, definiciones de páginas Web, registros de instancias de portlets y valores preferidos.
- Si el módulo de provisión está instalado, se conserva la información de estado del flujo de trabajo en la base de datos. Las definiciones de flujo de trabajo reales se almacenan en el repositorio seguro de identidades.
- Registros de Novell Audit
1.3.4 Motor del Gestor de identidades
El Gestor de identidades está formado por un motor del tiempo de ejecución, controladores y directivas. El motor del Gestor de identidades responde a los eventos del repositorio seguro de identidades y gestiona el flujo y la transformación de los datos que van o vienen del repositorio. Los objetos Controlador encapsulan el código ejecutable y artefactos (como documentos de directivas) diseñados para proporcionar comportamientos de manejo de datos específicos de un sistema conectado concreto. La aplicación de usuario del Gestor de identidades es un sistema conectado. La comunicación entre el repositorio seguro de identidades, el nivel de abstracción de la aplicación de usuario y el motor del flujo de trabajo se produce a través del controlador de la aplicación de usuario (véase abajo).
Dado que la aplicación de usuario se basa en varios objetos del directorio para almacenar artefactos de nivel de abstracción, es preciso extender el esquema de eDirectory para que albergue los objetos LDAP personalizados y los atributos que la aplicación de usuario necesita. La extensión del esquema se produce automáticamente como parte del proceso de instalación del Gestor de identidades. No obstante, la cumplimentación de los atributos y objetos personalizados con valores por defecto no se producirá hasta que se instale y active el controlador de la aplicación de usuario.
1.3.5 Controlador de la aplicación de usuario
El controlador de la aplicación de usuario es una pieza de habilitación importante de la aplicación de usuario. Una de las responsabilidades del controlador de la aplicación de usuario consiste en notificar al nivel de abstracción que han cambiado valores de datos importantes en el repositorio seguro de identidades, a fin de que el nivel de abstracción sepa que tiene que actualizar su caché.
Si el módulo de provisión está instalado, el controlador de la aplicación de usuario puede configurarse para que inicie automáticamente flujos de trabajo como respuesta a los cambios efectuados en los valores de los atributos en el repositorio seguro de identidades.
El controlador de la aplicación de usuario no sólo es un componente de tiempo de ejecución, sino también una empaquetadora de almacenamiento de objetos del directorio (incluidos los artefactos de tiempo de ejecución de la aplicación de usuario). A continuación, mostramos una representación habitual de los artefactos del directorio asociados al controlador de la aplicación de usuario.
NOTA:Los nombres mostrados representan valores de nombre común (cn) de LDAP. La denominación de esquema real de las diversas clases de objetos se trata en otro punto.
Estas categorías de artefactos se tratan abajo más detalladamente.
Objeto Conjunto de controladores
En todas las instalaciones del Gestor de identidades es preciso que los controladores se agrupen en conjuntos. Sólo puede haber un conjunto de controladores activo a la vez (en un servidor de directorios determinado). Los controladores de dicho conjunto se pueden activar o desactivar individualmente, sin que ello repercuta sobre el conjunto de controladores en general. El controlador de la aplicación de usuario (al igual que cualquier otro controlador IDM) debe existir dentro de un conjunto de controladores. La aplicación de usuario no crea automáticamente el conjunto de controladores; es preciso crear un conjunto de controladores con anterioridad y, después, crear el controlador de la aplicación de usuario dentro de éste.
Controlador de la aplicación de usuario
El objeto Controlador de la aplicación de usuario (al que se puede asignar un nombre de forma arbitraria) contiene una serie de artefactos. Al igual que ocurre con todos los controladores del Gestor de identidades, el controlador de la aplicación de usuario aplica directivas y objetos de canal Suscriptor y Editor. La aplicación de usuario no utiliza el canal Editor, aunque está disponible para utilizar en caso de personalización.
Objeto AppConfig
El objeto AppConfig es un contenedor de diversos objetos de configuración de la aplicación de usuario:
RequestDefs
Contenedor de definiciones de peticiones de provisión; es decir, contiene las definiciones de peticiones configuradas por el administrador disponibles para el tiempo de ejecución de la aplicación de usuario (si el módulo de provisión existe). Las definiciones almacenadas aquí (como XML) representan las clases de peticiones de las que los usuarios finales que tengan los derechos adecuados pueden crear instancias mediante la aplicación de usuario. RequestDef asocia un WorkFlowDef (abajo) con un ResourceDef.
WorkFlowDefs
Contenedor para objetos Flujo de trabajo, incluidos descripciones de tiempo de diseño y cualquier plantilla o flujo sin utilizar.
ResourceDefs
Contenedor para definiciones de recursos provisionados, incluidos descripciones de tiempo de diseño y cualquier plantilla o destino sin utilizar.
ServiceDefs
Contenedor para objetos de definición de servicios, que empaquetan los Servicios Web llamados por los Flujos de trabajo.
DirectoryModel
Objetos de metanivel del nivel de abstracción (ChoiceDefs, EntityDefs, RelationshipDefs), que representan diferentes tipos de contenido (algunos definibles por el usuario, otros definidos por el administrador) del directorio y que los portlets de identidad pueden exponer.
AppDefs
Contenedor de objetos Configuración utilizado para inicializar el entorno de tiempo de ejecución como, por ejemplo, la información de configuración del caché y las propiedades de las notificaciones por correo electrónico.
ProxyDefs
Contenedor de definiciones de apoderados (proxy).
DelegateeDefs
Contenedor de definiciones de delegados.
1.3.6 Nivel de abstracción del directorio
Los portlets obtienen los datos de identidad mediante consultas efectuadas al nivel de abstracción del directorio, que es un nivel de código que aísla los detalles de acceso de los datos de identidad de los procesos cliente. Cuando, por ejemplo, un portlet necesita efectuar una búsqueda en datos de identidad, el nivel de abstracción efectúa, en nombre del portlet, las consultas LDAP adecuadas en el contenedor de destino del repositorio seguro de identidades. En ningún momento, ningún portlet efectúa consultas directas en el repositorio seguro de identidades.
El nivel de abstracción es también el nivel de código a través del cual se crean o cambian las definiciones del nivel de abstracción, tal como las especifican los administradores u otros usuarios cualificados del sistema. Para efectuar tales cambios, el experto en sistemas utiliza el editor del nivel de abstracción del directorio de la aplicación del diseñador, descrita más adelante en esta guía, en Sección 4.0, Configuración del nivel de abstracción del directorio.
En el momento de ejecución, el nivel de abstracción almacena en caché una serie de datos de definición de entidades y de configuración obtenidos del repositorio seguro de identidades. El administrador puede gestionar con gran precisión los diversos cachés que mantiene la aplicación de usuario. Para obtener información adicional acerca de cachés y de gestión de cachés, consulte Sección 13.0, Configuración del almacenamiento en caché.
1.3.7 Motor del flujo de trabajo
El motor del flujo de trabajo (disponible con el módulo de provisión) es el conjunto de clases de tiempo de ejecución responsable de ejecutar los pasos de un flujo de trabajo, tal como están especificados en una definición de proceso (un artefacto de tiempo de ejecución creado cuando se crea una instancia de un flujo de trabajo) y de realizar el seguimiento de la información de estado, que se conserva en una base de datos como MySQL u Oracle; consulte Sección 1.3.3, Base de datos, arriba.
Encontrará información adicional acerca del sistema de flujo de trabajo, incluido cómo crear flujos de trabajo, más adelante, en el capítulo llamado Sección 21.0, Introducción a la provisión basada en el flujo de trabajo de esta guía.
1.3.8 Interfaz de usuario
La interfaz de usuario del Gestor de identidades está formada por un conjunto de portlets que cumplen con SR168 (y, en el caso del módulo de provisión, algunas páginas de servidor Java), que se ejecutan dentro de unas aplicaciones Web Java en JBoss. La arquitectura de portlets permite un alto grado de modularidad, personalización de contenido y control de usuario sobre el aspecto de las páginas. La estructura de la aplicación de usuario proporciona servicios de contenedor de diversos tipos. Gestiona el estado de la ventana, las preferencias de los portlets, la consolidación, el almacenamiento en caché, los temas, los registros, etc. y actúa como vigilante de seguridad. Por su parte, el servidor de aplicación en el que se ejecuta la aplicación de usuario proporciona diversos servicios a la aplicación en general como, por ejemplo, la capacidad de ampliación mediante la agrupación en clúster, el acceso a la base de datos a través de JDBC y el soporte para la seguridad basado en certificados.
El alto grado de encapsulación que permite esta arquitectura proporciona un entorno de presentación sólido y seguro para la aplicación de usuario del Gestor de identidades. Asimismo, garantiza un alto grado de control administrativo sobre todos los aspectos de la interfaz de usuario.
Para obtener más información acerca de cómo administrar las diversas partes de la interfaz de usuario, consulte varios capítulos de esta guía en Sección III, Administración de la aplicación de usuario.