1.3 Visão geral de alto nível da arquitetura
O aplicativo de usuário do Identity Manager depende de diversos componentes independentes que funcionam em conjunto. Os componentes básicos e suas responsabilidades fundamentais estão descritos na tabela a seguir.
Em termos de fluxo de informações, os componentes mencionados acima estão vinculados de modo lógico da maneira ilustrada no diagrama a seguir. Os componentes individuais podem estar (e, na maioria dos casos, estarão) fisicamente localizados em mais de uma máquina. Por exemplo, embora o cofre de identidade (e sua principal ferramenta de administração, o iManager) esteja localizado na máquina que hospeda o mecanismo do Identity Manager, o JBoss (e o aplicativo de usuário) estarão geralmente localizados em uma máquina separada (ou em um grupo de máquinas, caso sejam usados clusters). Da mesma forma, não apenas por questões de desempenho, mas também de segurança e recuperação de desastres, o banco de dados (MySQL) geralmente está instalado em uma máquina própria.
1.3.1 Cofre de identidade
O cofre de identidade é usado para armazenar dados de identidade e definições da camada de abstração de diversos tipos. Uma instância do eDirectory (executada no Windows, Solaris ou Linux) é usada para esse fim. Usando o eDirectory, o Identity Manager pode tirar proveito do diretório LDAPv3, um diretório comprovado de classe empresarial e escalável, com recursos de particionamento e replicação, além de uma ferramenta flexível de configuração e gerenciamento baseada na Web (iManager) que oferece um ponto de integração administrativa completo entre o Identity Manager e o próprio eDirectory.
1.3.2 JBoss
O aplicativo de usuário é fornecido em um pacote como um arquivo de aplicativo Java Web, ou arquivo WAR (Web Application Archive). O arquivo WAR é distribuído ao JBoss, o popular servidor de aplicativos Java de código-fonte aberto (que usa o Tomcat como seu mecanismo de servlet; não mostrado no diagrama). O uso do JBoss como um ambiente de execução traz diversas vantagens, dentre elas:
- O código-fonte está livremente disponível.
- O JBoss pode ser implementado em cluster a partir da versão 4.0.3.
- O JBoss é totalmente compatível com J2EE, o que significa que aplicativos J2EE podem ser executados nele. Aplicativos adicionais (por exemplo, Serviços Web) podem ser executados na mesma instância do JBoss usada pelo aplicativo de usuário.
- O JBoss oferece suporte a serviços de autorização e segurança Java JAAS e JACC padrão (dos quais o aplicativo de usuário depende para o acesso ao cofre de identidade).
- O JBoss pode ser executado em diversas plataformas, incluindo versões populares do Windows e Linux.
O WAR do aplicativo de usuário contém código executável para o aplicativo de usuário, que, por sua vez, é criado usando a arquitetura MVC (Model-View-Controller), a fim de separar os componentes. A interface do usuário é executada como portlets modulares no aplicativo de usuário. Há portlets separados para a exibição de organogramas, a realização de pesquisas, a exibição de detalhes de usuários, a redefinição de senhas e assim por diante.
Para obter mais informações sobre os diversos aspectos da distribuição de aplicativos Web ao JBoss, consulte a documentação do JBoss em http://www.jboss.org/products/jbossas/docs.
1.3.3 Banco de Dados
O aplicativo de usuário depende de um banco de dados (por padrão, MySQL; consulte o Guia de Instalação para obter uma lista dos banco de dados com suporte) para armazenar diversos tipos de informações:
- Dados de configuração do aplicativo de usuário: por exemplo, definições de página da Web, registros de instâncias de portlet e valores preferenciais.
- Se o Módulo de Aprovisionamento estiver instalado, as informações de estado de workflow serão mantidas no banco de dados. (As definições de workflow reais serão armazenadas no cofre de identidade.)
- Registros do Novell Audit
1.3.4 Mecanismo do Identity Manager
O produto Identity Manager consiste em um mecanismo de tempo de execução, drivers e políticas. O mecanismo do Identity Manager responde a eventos no cofre de identidade e gerencia o fluxo e a transformação de dados de entrada e saída do cofre de identidade. Objetos driver contêm código executável e artefatos (como documentos de política) projetados para proporcionar comportamentos de manipulação de dados específicos a um determinado sistema conectado. O aplicativo de usuário do Identity Manager é um sistema conectado. A comunicação entre o cofre de identidade, a camada de abstração do aplicativo de usuário e o Mecanismo de Workflow ocorre por meio do Driver de Aplicativo do Usuário (veja abaixo).
Como o aplicativo de usuário depende de diversos objetos diretório para o armazenamento de artefatos da camada de abstração, é necessário expandir o esquema do eDirectory para acomodar objetos e atributos LDAP personalizados necessários ao aplicativo de usuário. A expansão do esquema ocorre automaticamente como parte do processo de instalação do Identity Manager. Contudo, o preenchimento com objetos e atributos personalizados com valores padrão só ocorre depois que o Driver de Aplicativo do Usuário é instalado e ativado.
1.3.5 Driver de Aplicativo do Usuário
O Driver de Aplicativo do Usuário é um componente essencial do aplicativo de usuário. Uma das responsabilidades do Driver de Aplicativo do Usuário é notificar a camada de abstração quando valores de dados importantes são mudados no cofre de identidade, de modo que a camada de abstração saiba que deve atualizar seu cache.
Se o Módulo de Aprovisionamento estiver instalado, o Driver de Aplicativo do Usuário poderá ser configurado para acionar automaticamente os workflows em resposta a mudanças nos valores de atributo no cofre de identidade.
O Driver de Aplicativo do Usuário não é apenas um componente de tempo de execução, mas também um agrupador de armazenamento para objetos diretório (englobando os artefatos de tempo de execução do aplicativo de usuário). A seguir está uma representação típica de artefatos de diretório associados ao Driver de Aplicativo do Usuário.
NOTA:Os nomes mostrados representam valores de nome comum (cn) do LDAP. A nomeação de esquema real de diversas classes de objetos é abordada em outra parte.
Essas categorias de artefatos são abordadas com mais detalhes abaixo.
Objeto conjunto de drivers
Todas as instalações do Identity Manager exigem que os drivers sejam agrupados em conjuntos de drivers. Apenas um conjunto de drivers pode estar ativo por vez (em um determinado servidor de diretório). Os drivers naquele conjunto podem ser ativados ou desativados individualmente, sem afetar o conjunto de drivers como um todo. O Driver de Aplicativo do Usuário (assim como qualquer outro driver IDM) deve existir em um conjunto de drivers. O conjunto de drivers não é criado automaticamente pelo aplicativo de usuário; você deve criá-lo previamente e, em seguida, criar o Driver de Aplicativo do Usuário a ser inserido naquele conjunto.
Driver de Aplicativo do Usuário
O objeto Driver de Aplicativo do Usuário (que pode receber qualquer nome desejado) é o container de diversos artefatos. Assim como todos os drivers do Identity Manager, o Driver de Aplicativo do Usuário implementa os objetos e as políticas dos canais do Editor e do Assinante. O canal do Editor não é usado pelo aplicativo de usuário, embora esteja disponível para cenários com uso personalizado.
Object App Config (0)
O objeto AppConfig é um container para vários objetos de configuração de aplicativo de usuário:
RequestDefs
Esse é um container de Definições de Solicitação de Aprovisionamento, que são as definições de solicitação configuradas pelo administrador disponíveis para o tempo de execução do aplicativo de usuário (caso o Módulo de Aprovisionamento exista). As definições aqui armazenadas (em formato XML) representam as classes de solicitações que podem ser instanciadas por usuários finais com direitos apropriados por meio do aplicativo de usuário. O RequestDef associa um WorkFlowDef (abaixo) a um ResourceDef.
WorkFlowDefs
Um container para objetos Workflow, incluindo descrições de tempo de design e os gabaritos ou fluxos não utilizados.
ResourceDefs
Um container para definições de Recurso Aprovisionado, incluindo descrições de tempo de design e os gabaritos ou destinos não utilizados.
ServiceDefs
Um container para objetos Definição de Serviço, que agrupa Serviços Web chamados pelos Workflows.
DirectoryModel
Objetos de meta-nível da camada de abstração (ChoiceDefs, EntityDefs, RelationshipDefs), que representam diferentes tipos de conteúdo (alguns podem ser definidos pelo usuário e outros são definidos pelo administrador) do diretório que pode ser exposto pelos Portlets de Identidade.
AppDefs
Um container para objetos de configuração usados para inicializar o ambiente de tempo de execução, como as informações de configuração de cache e as propriedades de notificação de e-mail.
ProxyDefs
Um container para definições de proxy.
DelegateeDefs
Um container para definições de delegado.
1.3.6 Camada de abstração de diretório
Os portlets obtêm seus dados de identidade por meio de consultas à camada de abstração de diretório, uma camada de código que isola detalhes do acesso aos dados de identidade dos processos de cliente. Por exemplo, quando um portlet precisa realizar uma pesquisa de dados de identidade, a camada de abstração faz as consultas LDAP apropriadas em nome do portlet, usando para isso o container de destino no cofre de identidade. Um portlet nunca faz consultas diretas no cofre de identidade.
A camada de abstração é também a camada de código mediante a qual são criadas ou mudadas as definições de camada de abstração, conforme especificadas pelos administradores ou outros usuários qualificados do sistema. Para fazer essas mudanças, o especialista em sistema usa o editor da camada de abstração de diretório do aplicativo Designer, descrito mais adiante neste guia em Seção 4.0, Configurando a Camada de Abstração do Diretório.
No tempo de execução, a camada de abstração mantém em cache diversos tipos de dados de configuração e definição de entidade obtidos do cofre de identidade. Os diversos caches mantidos pelo aplicativo de usuário podem ser gerenciados em detalhes pelo administrador. Para obter mais informações sobre caches e gerenciamento de cache, consulte o Seção 13.0, Configuração de cache.
1.3.7 Mecanismo de workflow
O mecanismo de workflow (disponível no Módulo de Aprovisionamento) é o conjunto de classes de tempo de execução responsável pela execução das etapas de um workflow de acordo com uma definição de processo (um artefato de tempo de execução criado quando uma instância de workflow é criada) e pelo monitoramento das informações de estado, que são mantidas em um banco de dados, como MySQL ou Oracle; consulte a Seção 1.3.3, Banco de Dados, acima.
Há detalhes adicionais sobre o sistema de workflow, inclusive a maneira de criar workflows, no capítulo Seção 21.0, Introdução ao aprovisionamento com base em workflow, mais adiante neste guia.
1.3.8 Interface do usuário
A interface do usuário do Identity Manager é composta de um conjunto de portlets compatíveis com JSR168 (e, no caso do Módulo de Aprovisionamento, algumas Páginas do Servidor Java) que é executado em um aplicativo Web Java no JBoss. A arquitetura de portlet proporciona uma ampla utilização de módulos, bem como personalização de conteúdo e controle da aparência da página pelo usuário. A estrutura do aplicativo de usuário fornece serviços de container de diversos tipos. Ela gerencia o estado da janela, as preferências de portlet, a persistência, o armazenamento em cache, os temas, o registro e assim por diante, além de agir como guardião da segurança. O servidor de aplicativos no qual o aplicativo de usuário é executado proporciona vários serviços ao aplicativo como um todo, como escalabilidade por meio de clusters, acesso ao banco de dados via JDBC e suporte à segurança baseada em certificado.
O alto grau de encapsulação oferecido por essa arquitetura proporciona um ambiente de camada de apresentação seguro e robusto ao aplicativo de usuário do Identity Manager. Ela garante também um alto grau de controle administrativo em relação a todos os aspectos da interface de usuário.
Para obter mais informações sobre a administração dos diversos aspectos da interface de usuário, consulte os vários capítulos da Seção III, Administrando o aplicativo de usuário deste guia.