Dalla prossima versione del sistema operativo Microsoft, che chiameremo per semplicità Windows 8, sarà introdotta una modalità in più per l’autorizzazione degli utenti, il Dynamic Access Control che utilizzerà la Claim Based Authentication, cioè Active Directory Federation Services 2.0.

Attraverso il DAC ed AD FS sarà possibile autorizzare le persone dinamicamente in quanto i claim vengono formati e firmati da AD FS nel momento in cui l’utente chiede di accedere alla risorsa e non in fase di logon. Oltre a questo dettaglio già rivoluzionario di suo sarà possibile discriminare in base ad altri tipi di valori presenti nelle proprietà dell’utente come ad esempio di Department, il Codice Fiscale, il Ruolo Aziendale oppure ogni altra informazione presente in Active Directory. Quindi se una regola di accesso ad una cartella sul file system prevede il diritto read per tutti coloro che hanno nel campo Department di AD la parola “Magazzino” basterà tenere questo campo aggiornato e non servirà più mettere o togliere gli utenti dai gruppi security del dominio. E fin qui, per quanto bello ed utile, può sembrare superfluo in quanto aggiunge una funzionalità della quale possiamo fare tranquillamente a meno. Ma se approfondiamo il discorso ed analizziamo la potenza di AD FS ci rendiamo conto che possiamo autorizzare anche utenti che non sono all’interno del mio dominio senza necessariamente effettuare una relazione di trust tra i domini dove appartengono le risorse e gli utenti. Potrò quindi “federare” il mio AD FS con altri Identity Provider, anche non Microsoft, e delegare l’uso dei loro claims all’interno dell’autorizzazione delle mie cartelle condivise. In questo modo non avrò bisogno di creare nel mio dominio gli account per i consulenti, o clienti e fornitori, che vengono a lavorare nella mia rete interna.

Finalmente vediamo la luce in fondo al tunnel, siamo consci che in futuro esisterà uno strumento unico di autenticazione ed autorizzazione finalizzato all’eliminazione delle decine e decine di account, con relative password, che ognuno di noi possiede per ogni sito, servizio o cliente che frequenta.

“Un sistema di identità universale deve supportare informazioni “omni-direzionali” per il loro utilizzo pubblico e “mono-direzionali” per l’utilizzo da parte di soggetti privati; in modo da facilitare la scoperta delle informazioni pubbliche evitando la diffusione di quelle private”

Ogni identità informatica deve confrontarsi sempre con altre identità o gruppi di identità digitali. Per ognuna di esse si deve decidere che certe informazioni vengono pubblicate facilmente ed altre meno. In altre parole possiamo dire che un’identità possiede una direzione che regola la pubblicazione delle informazioni, si definisce omni-direzionale quando l’informazione della mia identità e’ pubblica, per esempio il mio sito web, oppure mono-direzionate quando l’informazione della mia identità va protetta e data solo a chi decido io, per esempio il mio numero di telefono. La diffusione delle informazioni e’ quindi direzionata nei confronti di altre identità (rendo visibile il mio numero di telefono a Gianni) oppure di gruppi di identità (il mio sito web è visibile a tutti mentre il mio ruolo in azienda è visibile solo ai miei colleghi).

Entità (claim) pubblici possono avere identificatori ben noti. Questi identificatori, se pubblici, possono essere considerati come dei fari di segnalazione che emettono informazioni a chiunque si presenti. Se i fari sono omni-direzinoali sono disposti a rilevare la loro esistenza ed a rispondere a qualsiasi entità si presenti e ne richieda il dato.

Un sito web personale come anche il certificato di chiave pubblica della firma elettronica sono un esempio di informazioni dell’identità digitale che devono essere pubblici. Non vi è alcun vantaggio nel renderli privati, anzi, ci sono solo svantaggi a tenerli nascosti o a modificarli spesso. Un altro esempio per far capire l’identità completamente pubblica, che possiede un solo identificatore pubblico omni-direzionale per tutte le informazioni che contiene, è un videoproiettore in una sala conferenze che permette a tutti i visitatori di guardare tutte le informazioni che contiene indipendentemente da chi passa e da chi le chiede.

Per contro ci sono utenti che visitano i siti web e vogliono godere di servizi offerti da tali siti (acquistare, vendere, commentare), in tal caso devono creare inevitabilmente dei rapporti coi siti stessi. L’utente sceglie di instaurare un rapporto mono-direzionale con il sito decidendo quali informazioni saranno disponibili al sito e quali no attraverso la scelta dell’identificatore adeguato. Un identificatore molto restrittivo permetterà il passaggio di informazioni sensibili, come la carta di credito, solo quando l’utente decide di fare degli acquisti mentre un identificatore permissivo darà al sito la possibilità di usare la foto ed il nickname per fare dei commenti in un blog. Per ogni sito diverso l’utente creerà un rapporto mono-direzionale specifico usando identificatori diversi per esporre dati diversi.

Quando un utente entra nella sala conferenze col videoproiettore riceve la richiesta dal faro omni-direzionale di interazione con lui. L’utente, attraverso la prima legge del Controllo, decide se interagire con lui stabilendo una piccola relazione mono-direzionale usando questa quarta legge della Direzione e decidendo quale identificatore usare per il passaggio delle sue informazioni proprio come specificato dalla legge di Divulgazione Minima.

La tecnologia Bluethoot, come altre tecnologie wireless, non sono conformi alla regola della Direzione dell’Identità. Usano fari pubblici verso soggetti privati che, se decidono di connettersi, non hanno possibilità di scegliere un rapporto mono-direzionale ma sono connessi assieme a tutti coloro che hanno deciso di farlo. Un altro esempio di tecnologia poco apprezzata dagli utenti è RFID (Radio Frequency IDentificator) per i passaporti o per le tessere universitarie. Il dispositivo dell’utente risponde con le sue informazioni a chiunque sia nelle vicinanze e glielo chieda senza poter scegliere di permetterlo o negarlo.

Il legislatore sta cominciando a capire la problematica della Direzione dell’Identità ed i tecnici devono lavorare di più con lui per anticipare le problematiche attraverso misure adeguate ad ogni contesto ed applicazione.

- Multiple Issuer Support, rilascio di token differenti per foreste che hanno più domini con radici di nomi diverse (UPN: @dominio.eu, @dominio.it)

- Client Access Policy Support, pieno supporto ad Office365 nelle policy con le quali si può limitare e controllare l’uso delle autenticazioni federate in SSO

- Congestion Avoidance Algorithm, introduzione di alcuni parametri per controllare gli attacchi DoS

- Additional AD FS 2.0 performance counters, aumento del numero dei counter per il controllo ed il monitoraggio dei server AD FS 2.0

Questo UR1 sostituisce ed include 2 aggiornamenti precedentemente rilasciati, KB2254256 e KB2272757 e deve essere installato in tutti i Federation Server e Federation Server Proxy della farm in versione RTW. Sono inclusi tutti i linguaggi qunidi non è un problema se avete installato i server con AD FS 2.0 in italiano, inglese o un’altra lingua.

I sistemi operativi dei server devono essere almeno Windows Server 2008 R2 RTM o SP1 oppure Windows Server 2008 SP2 anche se consigliamo caldamente (quasi obblighiamo) l’aggiornamento puntuale di ogni security update sui Federation Server e Federation Server Proxy.

L’aggiornamento deve essere richiesto compilando i campi ed inserendo la propria email in questa pagina tenendo conto che per Windows Server 2008 si deve scegliere Windows Vista (!?!). Attenzione anche all’architettura, in Vista/2008 c’è sia x86 che x64.

Tutti i dettagli dell’aggiornamento sono disponibili consultando la KB2607496.

Per verificare la corretta installazione controllare, negli Installed Updates, che sia presente la KB2607496:

Per controllare che i files siano stati aggiornati, partendo dalla lista indicata nella KB2607496, verificare la versione nelle proprietà dei files. Nel nostro caso il Federation Server è un Windows Server 2008 R2 SP1 quindi la build è 6.1.7601.21xxx:

Non tutti i files di AD FS 2.0 vengono aggiornati dall’UR1, in tal caso si legge solo la versione RTW. L’esempio di questo file riporta la build 6.1.7600.16405 come prima dell’aggiornamento:

• Disinstallare la componente AD FS 2.0
• Ripulire IIS
• Ripulire Active Directory

I primi due passi devono essere eseguiti sia nel Federation Server che nel Federation Server Proxy (se installato).

Disinstallare la componente AD FS 2.0

Andare nel Control Panel - Program and Features – View installed updates. Nella sottocategoria Microsoft Windows selezionare Active Directory Federation Services 2.0 e premere Uninstall.

Ripulire IIS

AD FS 2.0, in fase di installazione e configurazione (sia sul Federation Server che sul Federation Server Proxy), crea due virtual directory nel Default Web Site (/adfs/ls e /adfs) ed un’application pool (ADFSAppPool).

Per rimuovere le virtual directory andare nell’IIS Manager (dentro agli Administrative Tools), selezionare il Default Web Site e selezionare, una dopo l’altra, le due virtual directory (/adfs/ls e /adfs), premere il tasto destro e poi Remove.

Analogamente per l’application pool andare in Application Pools, selezionare ADFSAppPool e premere Remove.

Per concludere cancellare la cartella con i files del sito che, in genere, si trova in C:\inetpub\adfs. Cliccare la cartella adfs e rimuoverla con tutto il suo contenuto.

Ripulire Active Directory

Il wizard di configurazione di AD FS 2.0 crea in Active Directory un container (CN=ADFS,CN=Microsoft,CN=Program Data,DC=dominio,DC=locale) dove inserisce i certificati usati dal Federation Server. Questo container viene usato da tutti i Federation Server della Farm come anche dal singolo server che si installa nel dominio. Per rimuovere completamente una precedente installazione di AD FS senza lasciare traccia nel dominio deve essere rimosso questo container.

Avviare il comando adsiedit.msc con un utente amminstratore di dominio. Tasto destro su ADSI Edit e premere Connect to… poi lasciare selezionato il Default naming context nell’area selezionata Select a well known Naming Context e premere OK. Sfogliare il proprio dominio fino a CN=Program Data, CN=Microsoft e CN=ADFS quindi selezionare CN=ADFS e cancellare tutti i sotto container con tasto destro e Delete.

Qui la KB982813 di riferimento dove trovare queste ed altre utili informazioni.

Per esempio, i:0#.w|DOMINIO\utente cosa vuol dire? Cosa significano i caratteri iniziali?

i: Claim Identificativo univoco per l’utente. Tramite il descrittore dopo il carattere | è possibile identificare univocamente l’utente (logonname, codice fiscale, email) mentre quando il claim è descrittivo dell’utente senza essere univoco (ruolo aziendale, residenza) si usa il prefisso c:

0 (zero) riservato per futuri utilizzi quindi non ha significato e si trova sempre visualizzato con lo stesso valore

# (cancelletto) Claim Type Encoded Value. Quale tipologia di dato viene usato come descrittore, in base a questa tabella si identificano i caratteri possibili. Il carattere # (cancelletto) è lo user logon name di dominio dell’utente.

. (punto) Claim Value Type. Quale tipo di dato viene usato nel descrittore, in base a questa tabella si identificano i tipi possibili. Il carattere . (punto) è il tipo stringa.

w Original Issuer Type. Il provider di autenticazione che fornisce originariamente il descrittore, in base a questa tabella si identificano i provider possibili. Il carattere w è il tipo windows (Local o dominio Active Directory)

| (pipe) Separatore tra i caratteri che indicano il significato dei dati del descrittore ed il vero e proprio descrittore identificativo.

DOMINIO\utente Descrittore identificativo, in base ai caratteri precedenti è possibile dare un maggiore significato. Nel nostro caso è quindi una stringa che identifica univocamente l’utente tramite il logon name del dominio Active Directory.

Analogamente possiamo dare significato anche a questi claims:

i:05.t|ADFSprovider|n.cognome@azienda.it Identificato univoco dell’utente (i:0) tramite email (5) come stringa (.) e rilasciato da un Identity Provider trustato dall’applicazione (t), questo IdP si chiama ADFSprovider e la mail dell’utente è n.cognome@azienda.it

i:0#.w|nt authority\network service Identificato univoco dell’utente (i:0) tramite logonname (#) come stringa (.) e rilasciato da Windows (w), l’account di sistema è locale del server (nt authority) e per la precisione si tratta del network service

i:0#.m|fbamembership|adminfba Identificativo univoco dell’utente (i:0) tramite logonname (#) come stringa (.) e rilasciato da un provider FBA di tipo .Net (m), il provider si chiama fbamembership e l’account è adminfba

c:0[.c|crmclaimprovider|11027 Identificativo non univoco dell’utente (c:0) tramite il codice d’avviamento postale ([) come stringa (.) e rilasciato da un claim provider chiamato crmclaimprovider con valore 11027

“I sistemi di gestione delle identità devono essere progettati in modo che la divulgazione delle informazioni identificative sia limitata alle parti che svolgono un ruolo necessario e legittimato all’interno del rapporto di identificazione”

Il sistema di identificazione deve fare in modo che il suo utente sia perfettamente e consapevolmente a conoscenza delle parti (siti, sistemi, applicazioni) con cui interagirà attraverso la condivisione delle proprie informazioni.

I vincoli e requisiti di legittimazione si applicano sia al soggetto che offre le sue informazioni (utente), sia al sistema dove si autentica (Rely Party). L’esperienza vissuta con Microsoft Passport (ora Windows Live ID) è istruttiva a tale riguardo. Gli utenti internet sono stati molto entusiasti nell’usare un solo account per accedere a tutti i siti MSN (MicroSoft Network, Messenger, Hotmail ecc…) e gli stessi siti erano soddisfatti della gestione delle informazioni tant’è che si è arrivati ad oltre un miliardo di interazioni al giorno. Tuttavia non aveva molto senso per Microsoft favorire l’interazione tra Passport e la maggior parte dei siti non MSN, magari della concorrenza. Oltre a questo nessun utente ha chiesto a gran voce un singolo sistema di autenticazione Microsoft per tutte le loro interazioni con altri siti o applicazioni su internet. Questo dava infatti a Microsoft la capacità di sapere esattamente quando e come gli utenti andavano nelle loro navigazioni. Per questi motivi Passport ha fallito come sistema unico di identificazione su internet, anche se è tuttora molto usato.

Oggi alcuni governi stanno pensando di implementare soluzioni per offrire servizi di identità digitale. Ha senso, ed è chiaramente giustificabile, che i cittadini abbiano delle credenziali governative quando hanno a che fare con le istituzioni (comuni, asl, uffici pubblici). Ma sarà un passo culturale molto forte il fatto che questi cittadini, forti del principio di questa legge (necessarietà e legittimità) usino tali credenziali gestite dallo stato per accedere ai loro blog, alla posta elettronica o connettersi ad un sito per gli acquisti in rete, in banca o ad un’applicazione aziendale.

Gli stessi argomenti sono applicabili anche a sistemi di gestione delle identità digitali in azienda e/o nei luoghi di lavoro. Questa legge non ha lo scopo di proporre dei limiti a ciò che è possibile ma piuttosto a delimitare le dinamiche delle quali dobbiamo essere perfettamente consapevoli.

La prima legge sul “Controllo ed assenso dell’utente” dice che il sistema deve essere prevedibile e trasparente al fine di guadagnare la fiducia dell’utente. Ma quest’ultimo deve essere messo in grado di capire bene il contesto di utilizzo delle sue informazioni come vedremo nella legge numero 6 “Interattività umana”. Nel mondo fisico, con la sua naturale lentezza, siamo in grado di giudicare una situazione e quali informazioni di noi vogliamo rivelare. Analogamente ci troviamo a dover giudicare la legittimità delle parti digitali (siti, applicazioni) che incontriamo su internet usando il nostro sistema di identità digitale.

Ogni controparte digitale che chiede i dati agli utenti deve fornire tutte le informazioni di utilizzo (policy) di questi dati. Questa policy deve definire i dettagli di cosa succede alle informazioni ed ogni individuo deve essere sempre in grado di accedervi per definire tutti i diritti di delega (delegated rights) nei confronti della controparte digitale.

Ogni detentore delle informazioni è in grado di comunicare con l’autorità giudiziaria in caso di indagini penali anche se questa non è definita come controparte specifica nella relazione delle identità digitali. A patto però che questo sia espressamente indicato all’interno delle regole (policy) di utilizzo di tali informazioni.

AD FS 2.0 implementa le seguenti funzionalità:

• Permette la creazione di un gestore di servizi claims (Claims Provider) all’interno dell’organizzazione per il trattamento delle identità digitali degli utenti di Active Directory nei confronti delle applicazioni basate sui claims (claims-based). Un’ applicazione scritta con la metodologia autenticativa claims-based ha diversi vantaggi in termini sistemistici tra i quali: permette il Single-Sign-On (SSO) con altre applicazioni (l’utente si autentica una sola volta per l’uso di più applicazioni diverse); permette l’accesso ad applicazioni compatibili (claims-aware) anche se implementate in altre organizzazioni; riduce notevolmente la gestione e la complessità dell’autenticazione uniformandola tra organizzazioni diverse che implementano tecnologie non Microsoft.
• Permette l’interfacciamento con ambienti autenticativi extradominio (domini federati) tramite la sola navigazione web. Si puo’ installare e configurare il ruolo AD FS 2.0 su uno o più  server in modo che, attraverso un semplice browser, si possa godere dell’autenticazione web in SSO tra domini diversi. Questo riduce le problematiche sistemistiche poichè non necessita di trust di dominio, vpn o quant’altro. Ogni dominio gestisce le sue utenze ed il tutto e’ ben protetto attraverso certificati X.509.
• L’uso è particolarmente semplice in quanto la creazione di una trust applicativa tra domini federati (anche non Active Directory) si effettua in pochi secondi attraverso lo scambio di metadati XML standard, firmati da certificati digitali, attraverso il web come la semplice visita di un sito. Lo scambio di certificati tra partner diversi è semplificato dallo standard e tutte le componenti comunicano automaticamente e periodicamente per mantenere attivo il sistema autonomamente.
• L’interfaccia di gestione è intuitiva e molto potente grazie allo snap-in MMC (Microsoft Management Console) 3.0 che permette una gestione grafica della componente ed alla presenza anche dell’estensione per PowerShell 2.0.

In atre parole AD FS 2.0:

• Abilita le organizzazioni alla colaborazione sicura tra domini Active Directory (e non solo) usando l’idenità digitale federata.
• Riduce il bisogno di duplicazione degli account ed altri strumenti di gestione delle credenziali permettendo il SSO federato su piattaforme ed applicazioni compatibili (cloud computing compreso).
• Permette la delega delle identità che autorizza le applicazioni ad impersonificare gli utenti all’interno delle infrastrutture tecnologiche dove questi non hanno account locali.
• Permette l’uso di smart-card ed altri sistemi di gestione della Multifactor Authetication per aumentare la sicurezza.

“La soluzione che svela la quantità minore di informazioni di identificazione e ne limita il suo utilizzo è la migliore e la più stabile a lungo termine”

Dovremmo costruire sistemi che impiegano le informazioni di identificazione mettendo in conto che una violazione è sempre possibile. Questo tipo di violazione rappresenta un rischio. Per ridurre i rischi, è meglio acquisire le informazioni solo sulla base di quello che si ha “bisogno di sapere” (need to know), e di conservarlo solo rispetto alla ”bisogno di mantenere” (need to retain). Seguendo queste pratiche, possiamo garantire il minor danno possibile in caso di violazione del sistema di gestione dell’identità.

In altre parole, il valore delle informazioni di identificazione diminuisce al diminuire della loro quantità. Un sistema costruito con i principi delle informazioni minime è quindi un obiettivo meno attraente per i ladri d’identità, ne consegue anche una riduzione del rischio.

Limitando la raccolta e l’uso delle informazioni, assieme alla regola descritta nella legge numero 1, si completa il principio “bisogno di sapere” (need to know) e la riduzione del rischio è ulteriormente migliorata. A questo punto non esiste più la possibilità di raccogliere e conservare le informazioni “non si sa mai” (just in case) per poter essere usate, forse, in futuro.

Il concetto di “minime informazioni di identificazione” (least identifying information) dovrebbe essere visto nel suo insieme e non solo come minor numero di dati raccolti e gestiti (claims), è da intendere come minor numero di informazioni in grado di identificare un dato individuo in contesti diversi. Per esempio, se uno scenario richiede la prova di avere una certa età, allora è meglio acquisire o calcolare un semplice numero per l’età, piuttosto che dare la data di nascita. Con la data di nascita infatti è più probabile, in associazione con altre eventuali informazioni, identificare univocamente un soggetto. Questo rappresenta quindi il concetto di “troppe informazioni di identificazione” (more identifying information), che dovrebbe essere evitato quando non è necessario.

Analogamente, identificatori univoci che possono essere riutilizzati in altri contesti (per esempio, il numero della patente, il codice fiscale, e così via) rappresentano “troppe informazioni di identificazione” (more identifying information) in quanto unici e di riferimento per organizzazioni importanti. In questo senso, l’acquisizione e la memorizzazione di un codice fiscale rappresenta un rischio molto maggiore rispetto alla gestione della matricola universitaria o del codice interno della propria azienda.

Sono numerose le catastrofi informatiche che si sono verificate per via della violazione di questa legge.

Possiamo anche definire la Legge di divulgazione minima in questo modo: l’aggregazione delle informazioni di identificazione unita al loro rischio. Per minimizzare i rischi, ridurre al minimo l’aggregazione.

“I sistemi di gestione delle identità devono rivelare informazioni di un utente solo con il suo controllo e consenso”

Nessuno elemento è più importante e fondamentale per il successo dei sistemi di autenticazione e di gestione delle identità digitali come l’individuo che lo utilizza. Il sistema deve prima di tutto attrarre in termini di convenienza e semplicità. Ma per resistere, deve guadagnarsi prima di tutto la fiducia dell’utente.

Guadagnare questa fiducia richiede un impegno olistico (miltidisciplinare, completo). Il sistema deve essere progettato in maniera che l’utente sia in grado di controllare perfettamente la sua identità digitale e le sue informazioni personali unite oltre a come queste vengono diffuse.

Il sistema deve anche proteggere l’utilizzatore dagli inganni, verificare l’identità delle terze parti che richiedono le informazioni. Se l’utente decide di fornire informazioni sulla sua identità, non ci deve essere alcun dubbio sul richiedente. Oltretutto il sistema ha bisogno di meccanismi per rendere l’utente cosciente degli scopi per i quali le informazioni vengono raccolte.

Il sistema deve informare l’utente quando lui o lei ha scelto un provider di identità in grado di monitorare le sue informazioni su Internet.

Inoltre, si deve rafforzare il senso che l’utente ha tutto sotto controllo, indipendentemente dal contesto, piuttosto che alterare arbitrariamente l’uso delle informazioni. Questo significa essere in grado di supportare il consenso dell’utente nel luogo di lavoro  come negli ambienti dove svolge degli acquisti. E ‘essenziale mantenere il paradigma del consenso, anche quando il rifiuto potrebbe rompere le condizioni di una società dove si lavora. Questo serve per informare, responsabilizzare e proteggere sia il lavoratore quanto il datore di lavoro.

La legge di “controllo ed assenso dell’utente” consente l’utilizzo di meccanismi di cui il sistema di gestione dell’identità ricorda le decisioni degli utenti in modo che essi possono scegliere di applicarle automaticamente in occasioni successive.

La rete Internet è stata progettata e costruita senza uno strumento preciso per sapere a chi e a che cosa ci si connette. Questo limita ciò che possiamo fare con la rete e ci espone a pericoli crescenti. Se non facciamo niente ci troveremo ad affrontare una rapida proliferazione di episodi di furto e inganno che andranno ad erodere progressivamente la fiducia del pubblico in Internet.

Abbiamo intrapreso un progetto per sviluppare una comprensione formale delle dinamiche che nascono dall’uso di sistemi di identità digitale in modo da avere successo o fallire nei vari contesti. Il tutto si riassume nelle leggi dell’identità. Prese insieme, queste leggi definiscono un sistema unificato di metadati che può offrire ad internet uno strumento teorico e pratico per la gestione dell’identità digitale. Esse forniscono anche uno strumento col quale le persone estranee al tema possano discutere di identità al fine di comprenderne i suoi temi centrali. Questo permette loro di unirsi attivamente al confronto, piuttosto che ognuno debba ricominciare da zero la discussione per poter capire o farsi capire dagli altri.

Quelli di noi che lavorano con sistemi di identificazione devono obbedire alle leggi dell’identità. Altrimenti, creiamo una scia di effetti collaterali che alla fine minano tutte le tecnologie che ne derivano. Il risultato è simile a quello che accadrebbe se gli ingegneri civili dovessero costruire i palazzi andando a mettere in dubbio la legge di gravità. Seguendo queste leggi possiamo costruire un sistema unificato di metadati per la gestione delle identità digitali che sarà ampiamente accettato, duraturo ed implementato attraverso molteplici sistemi informatici disomogenei.