1.3 Panoramica sull'architettura di alto livello

L'applicazione utente di Identity Manager si basa su diversi componenti indipendenti che interagiscono fra loro. Nella tabella seguente vengono descritti i componenti fondamentali e le relative attività di base.

Componente

Descrizione

Identity Vault (eDirectory 8.7.3 o 8.8)

Archivio per i dati utente (e altri dati di identità), driver e set di driver IDM, nonché per vari elementi dello strato di astrazione e, se è installato il modulo di provisioning, dei workflow.

Motore di Identity Manager

Costituisce il framework di runtime di Identity Manager che controlla gli eventi in eDirectory (e nei sistemi collegati) applicando le norme e instradando i dati da e verso l'Identity Vault.

Driver dell'applicazione utente

Il driver dell'applicazione utente comunica con quest'ultima per consentirne l'aggiornamento della cache in caso di modifiche delle definizioni dello strato di astrazione. Quando è installato il modulo di provisioning, è possibile configurare il driver in modo da consentire agli eventi nell'Identity Vault di attivare i workflow. Il driver, inoltre, comunica le informazioni di autorizzazione all'Identity Vault in modo che sia disponibile un record dell'autorizzazione concessa (o non concessa) al termine del workflow.

Applicazione utente: interfaccia utente Web

L'interfaccia utente Web dell'applicazione utente è un'applicazione Java basata su browser a cui vengono collegate le portlet conformi alla specifica JSR 168.

Applicazione utente: strato di astrazione

Lo strato di astrazione isola la logica dello strato di presentazione dall'Identity Vault, in modo che tutte le richieste di dati di identità debbano passare attraverso lo strato di astrazione. Il codice delle portlet non può ottenere un accesso diretto alle informazioni di identità. Tutte le richieste passano attraverso lo strato di astrazione e sono soggette alle sue restrizioni (ad esempio, quelle relative al controllo dell'accesso).

Applicazione utente: motore di workflow (disponibile solo con il modulo di provisioning)

Il motore di workflow è costituito da un insieme di eseguibili Java che si occupano della gestione e dell'esecuzione dei passaggi di un workflow definito dall'amministratore.

Server per applicazioni JBoss

Il server per applicazioni JBoss open source fornisce il framework di runtime in cui vengono eseguiti l'applicazione utente, lo strato di astrazione e il motore di workflow.

Database (MySQL per default)

Nel database (per l'elenco dei database supportati, vedere la Guida all'installazione) vengono memorizzati determinati tipi di informazioni di configurazione per conto dell'applicazione utente, nonché lo stato del workflow (se è installato il modulo di provisioning).

Driver del servizio Composer

Il driver del servizio Composer è una parte del driver dell'applicazione utente che può essere configurata in modo personalizzato per rispondere agli eventi nell'Identity Vault con l'attivazione dei workflow.

Novell Audit

Novell Audit è un server di registrazione indipendente in cui è possibile memorizzare in modo permanente diversi tipi di dati, ad esempio quelli generati dai passaggi di un workflow. Per ulteriori informazioni, vedere il capitolo relativo alla configurazione della registrazione, più avanti in questo manuale.

In termini di flusso delle informazioni, i componenti sopra indicati sono collegati logicamente come illustrato nel diagramma seguente. Dal punto di vista fisico, i singoli componenti possono essere situati in più computer, come di fatto avverrà nella maggior parte dei casi. Ad esempio, anche se l'Identity Vault e il suo principale strumento di amministrazione, iManager, verranno collocati nel computer in cui si trova il motore di Identity Manager, JBoss e l'applicazione utente verranno in genere situati in un computer o in un gruppo di computer, se gestiti in cluster, separato. Analogamente, per motivi non solo di prestazioni ma anche di sicurezza e recupero di emergenza, il database (MySQL) si troverà generalmente in un computer apposito.

Descrizione: Descrizione: illustrazione

1.3.1 Identity Vault

Nell'Identity Vault vengono memorizzati dati di identità e definizioni dello strato di astrazione di vario tipo. A questo scopo viene utilizzata un'istanza di eDirectory (in esecuzione su Windows, Solaris o Linux). Mediante eDirectory, Identity Manager può avvalersi di una directory LDAPv3 di classe aziendale, ampiamente scalabile e comprovata con funzionalità di partizionamento e replica, nonché di un flessibile strumento di configurazione e gestione basato sul Web (iManager) che fornisce un punto di integrazione amministrativa unico tra Identity Manager e eDirectory.

1.3.2 JBoss

L'applicazione utente è impacchetta come file WAR (Web Application Archive). L'archivio WAR viene distribuito in JBoss, il popolare server per applicazioni Java open source che utilizza Tomcat come motore servlet (non mostrato nel diagramma). L'utilizzo di JBoss come ambiente di esecuzione offre molti vantaggi, tra cui:

  • Il codice sorgente è disponibile liberamente.
  • A partire dalla versione 4.0.3, JBoss può essere gestito in cluster.
  • Essendo pienamente compatibile con le specifiche J2EE, JBoss consente l'esecuzione di qualsiasi applicazione J2EE. È possibile utilizzare applicazioni aggiuntive (ad esempio, servizi Web) nella stessa istanza di JBoss su cui viene eseguita l'applicazione utente.
  • JBoss supporta servizi di autorizzazione e sicurezza Java JAAS e JACC (su cui si basa l'applicazione utente per l'accesso all'Identity Vault).
  • JBoss può essere eseguito su molte piattaforme diverse, comprese le diffuse versioni di Windows e Linux.

Nel file WAR dell'applicazione utente è contenuto il codice eseguibile per l'applicazione utente, a sua volta compilato mediante un'architettura MVC (Model-View-Controller, Modello-Vista-Controller), per fini di separazione. Le interfacce con cui l'utente interagisce vengono eseguite come portlet modulari all'interno dell'applicazione utente. Sono disponibili portlet distinte per la visualizzazione degli organigrammi, l'esecuzione di ricerche, la visualizzazione dei dettagli utente, la reimpostazione delle parole d'ordine e così via.

Per ulteriori informazioni sui vari aspetti della distribuzione delle applicazioni Web su JBoss, consultare la documentazione JBoss all'indirizzo http://www.jboss.org/products/jbossas/docs.

1.3.3 Database

L'applicazione utente si serve di un database (MySQL per default; per l'elenco dei database supportati, vedere la Guida all'installazione) per la memorizzazione dei vari tipi di informazioni seguenti:

  • Dati di configurazione dell'applicazione utente, ad esempio definizioni delle pagine Web, registrazioni delle istanze delle portlet e valori delle preferenze.
  • Se è installato il modulo di provisioning, le informazioni sullo stato dei workflow vengono memorizzate in modo permanente nel database (le definizioni effettive dei workflow vengono memorizzate nell'Identity Vault).
  • Log di Novell Audit

1.3.4 Motore di Identity Manager

Il prodotto Identity Manager è costituito da un motore di runtime, driver e norme. Il motore risponde agli eventi nell'Identity Vault e gestisce il flusso e la trasformazione dei dati da e verso il Vault. Negli oggetti driver vengono incapsulati il codice eseguibile ed elementi (ad esempio i documenti di norme) intesi a fornire i comportamenti di gestione dei dati specifici di un determinato sistema collegato. L'applicazione utente di Identity Manager è un sistema collegato. La comunicazione tra l'Identity Vault, lo strato di astrazione dell'applicazione utente e il motore di workflow avviene tramite il driver dell'applicazione utente (vedere la sezione seguente).

Poiché l'applicazione utente si basa su vari oggetti di directory per la memorizzazione degli elementi dello strato di astrazione, è necessario estendere lo schema di eDirectory per contenere gli oggetti e gli attributi LDAP personalizzati necessari all'applicazione utente. Tale estensione viene eseguita in modo automatico nell'ambito del processo di installazione di Identity Manager. Tuttavia, la compilazione degli oggetti e degli attributi personalizzati con valori di default non viene eseguita fino a quando il driver dell'applicazione utente non viene installato e attivato.

1.3.5 Driver dell'applicazione utente

Il driver dell'applicazione utente costituisce una parte importante dell'applicazione utente. Uno dei suoi compiti è quello di notificare il cambiamento di valori di dati importanti nell'Identity Vault allo strato di astrazione, in modo che sia possibile aggiornarne la cache.

Se è installato il modulo di provisioning, è possibile configurare il driver dell'applicazione utente in modo da attivare automaticamente dei workflow a seguito di modifiche dei valori degli attributi nell'Identity Vault.

Questo driver non è solo un componente di runtime ma anche un wrapper per la memorizzazione di oggetti di directory (compresi gli elementi di runtime dell'applicazione utente). Di seguito è riportata una rappresentazione tipica degli elementi di directory associati al driver dell'applicazione utente.

Descrizione: Descrizione: illustrazione

NOTA:i nomi indicati rappresentano i valori dei nomi comuni (cn) LDAP. La denominazione effettiva delle varie classi di oggetti dello schema è trattata altrove.

Nei paragrafi seguenti vengono descritte più dettagliatamente queste categorie di elementi.

Oggetto Driver Set

Per ogni installazione di Identity Manager è necessario che i driver siano raggruppati in set di driver. Può essere attivo un solo set di driver alla volta in un determinato server di directory. I driver all'interno di tale set possono essere attivati o disattivati singolarmente senza che ciò abbia effetto sull'intero set di driver. Il driver dell'applicazione utente (analogamente a qualsiasi altro driver IDM) deve essere contenuto in un set di driver. Poiché il set di driver non viene creato automaticamente dall'applicazione utente, è necessario prima crearne uno e quindi creare il driver dell'applicazione utente al suo interno.

Driver dell'applicazione utente

L'oggetto driver dell'applicazione utente (a cui è possibile assegnare un nome qualsiasi) è il container di diversi elementi. Analogamente a tutti i driver di Identity Manager, questo driver consente l'implementazione degli oggetti e delle norme relativi ai canali produttore e sottoscrittore. Il canale produttore non viene utilizzato dall'applicazione utente, anche se disponibile per i casi di personalizzazione.

Oggetto App Config

L'oggetto AppConfig è un container per vari oggetti di configurazione dell'applicazione utente:

RequestDefs

Container per le definizioni delle richieste di provisioning, le definizioni delle richieste configurate dall'amministratore disponibili per il runtime dell'applicazione utente (se è presente il modulo di provisioning). Le definizioni memorizzate in formato XML rappresentano le classi delle richieste di cui gli utenti finali che dispongono dei diritti appropriati possono create istanze tramite l'applicazione utente. RequestDef consente di associare una WorkFlowDef (definita di seguito) a una ResourceDef.

WorkFlowDefs

Container per gli oggetti Workflow, comprese le descrizioni del tempo di progettazione ed eventuali modelli o flussi non utilizzati.

ResourceDefs

Container per le definizioni delle risorse soggette a provisioning, comprese le descrizioni del tempo di progettazione ed eventuali modelli o destinazioni non utilizzate.

ServiceDefs

Container per gli oggetti di definizione servizio, in cui vengono disposti i servizi Web richiamati dai workflow.

DirectoryModel

Oggetti a livello meta dello strato di astrazione (ChoiceDefs, EntityDefs, RelationshipDefs), che rappresentano tipi differenti di contenuto (alcuni definibili dall'utente, altri impostati dall'amministratore) della directory che può essere esposta dalle portlet di identità.

AppDefs

Container per gli oggetti di configurazione utilizzati per l'inizializzazione dell'ambiente di runtime, ad esempio informazioni di configurazione della cache e proprietà delle notifiche e-mail.

ProxyDefs

Container per le definizioni degli utenti incaricati.

DelegateeDefs

Container per le definizioni dei delegati.

1.3.6 Strato di astrazione directory

Le portlet ottengono i dati di identità tramite interrogazioni nello strato di astrazione directory, ovvero uno strato di codice in cui vengono isolati i dettagli di accesso ai dati di identità dai processi client. Ad esempio, quando una portlet deve eseguire una ricerca di dati di identità, lo strato di astrazione esegue le interrogazioni LDAP appropriate nel container di destinazione nell'Identity Vault, per conto della portlet. Una portlet non esegue mai interrogazioni dirette nell'Identity Vault.

Lo strato di astrazione è inoltre lo strato di codice attraverso cui vengono create o modificate le relative definizioni in base a quanto specificato dagli amministratori o da altri utenti autorizzati del sistema. Per l'esecuzione di tali modifiche, viene utilizzato l'editor dello strato di astrazione directory disponibile nell'applicazione di progettazione e descritto più avanti in questa guida in Sezione 4.0, Configurazione dello strato di astrazione directory.

In fase di runtime, lo strato di astrazione memorizza nella cache un'ampia varietà di dati di definizione entità e di configurazione ottenuti dall'Identity Vault. Le varie cache utilizzate nell'applicazione utente possono essere gestite a livello dettagliato dall'amministratore. Per ulteriori informazioni sulle cache e sulla relativa gestione, vedere Sezione 13.0, Configurazione della memorizzazione nella cache.

1.3.7 Motore di workflow

Il motore di workflow (disponibile con il modulo di provisioning) è l'insieme delle classi di runtime utilizzate per l'esecuzione dei passaggi di un workflow in base a quanto specificato da una definizione di processo (un elemento di runtime creato al momento della creazione dell'istanza del workflow) e per tenere traccia delle informazioni di stato, che vengono memorizzate in modo permanente in un database come MySQL o Oracle. Vedere Sezione 1.3.3, Database.

Per ulteriori dettagli sul sistema di workflow, comprese le modalità di creazione dei workflow, vedere Sezione 21.0, Introduzione al provisioning basato su workflow, più avanti in questa guida.

1.3.8 Interfaccia utente

L'interfaccia utente di Identity Manager è costituita da una raccolta di portlet conformi alla specifica JSR 168 e, in caso di modulo di provisioning, da alcune pagine JSP (Java Server Pages), che vengono eseguite all'interno di un'applicazione Web Java su JBoss. L'architettura delle portlet consente un grado elevato di modularità, di personalizzazione dei contenuti e di controllo dell'utente sull'aspetto delle pagine. Il framework dell'applicazione utente fornisce servizi di container di vario tipo. Gestisce lo stato delle finestre, le preferenze delle portlet, la memorizzazione permanente, la memorizzazione nella cache, i temi, le registrazioni e così via; agisce inoltre come gatekeeper di sicurezza. A sua volta, il server in cui viene eseguita l'applicazione utente fornisce all'applicazione stessa vari servizi, ad esempio la scalabilità attraverso la gestione in cluster, l'accesso al database tramite JDBC e il supporto per la sicurezza basata su certificati.

L'alto grado di incapsulamento consentito da questa architettura fornisce un ambiente a livello di presentazione efficiente e sicuro per l'applicazione utente di Identity Manager e garantisce inoltre un elevato controllo amministrativo su tutti gli aspetti dell'interfaccia utente.

Per ulteriori informazioni sull'amministrazione delle varie parti dell'interfaccia utente, consultare i vari capitoli di questa guida in Sezione III, Amministrazione dell'applicazione utente.