Breve nota di servizio: sono sommerso dalle attività, aiutooo! Tornato sabato dalla settimana a Redmond sono ancora in perenne rincorsa dei "task" in sospeso. Il livello di questo sovraccarico è testimoniato efficacemente dal numero di mail da smaltire presenti nella mia inbox (in questo istante sono 455, tra lette, parzialmente lette e non lette ...): non so se succede anche a voi, ma se non riesco a mettere ordine nelle email mi sembra di non avere il controllo esatto della mia pianificazione di lavoro. E' incredibile come le email siano diventate così importanti! Smettendo di lamentarmi (visto che sicuramente non sarò l'unico in questa situazione), volevo scusarmi con coloro che mi hanno scritto (siete sempre di più, grazie!) e non hanno ricevuto risposta... come vedete anche nel bloggare sono latitante!

Per riprendere velocità, (e tenendo conto del poco tempo a disposizione ... vi sto scrivendo dall'area WiFi di Fiumicino, vicino al gate A1 ;-)...) ho pensato di condividervi una parte dell'articolo che ho appena redatto per il numero di novembre/dicembre per la rivista ICT Security, sul tema Identity Metasystem (IDMS) & Windows CardSpace. E' passato davvero troppo tempo da quando ho iniziato a raccontarvi questa affascinante (la credo davvero tale!) proposizione tecnologica, ed è giusto completare la panoramica dei concetti di base prima di darvi nuovi interessanti aggiornamenti. Quindi se non l'avete già fatto, vi invito a leggete i miei due primi post al riguardo, "I have a dream ..." e "... come nasce l'IDMS" e poi tuffatevi nel seguito del post, direttamente e liberamente estratto dall'articolo di cui detto.

Avevo terminato il post dicendo che l'Identity Metasystem ambisce ad avere per Internet lo stesso ruolo per le identità che ha avuto il TCP/IP per i protocolli di rete: un modello per l’interoperabilità tra i sistemi eterogenei di identità, in grado di fornire alle applicazioni una rappresentazione delle identità digitali indipendente dalla tecnologia e di fornire all’utente una esperienza d’uso semplice, consistente e sicura.

Le “Laws of Identity”

L’ingegnerizzazione di tale architettura è avvenuta a seguito di un ampio dialogo pubblico realizzato da Kim Cameron (attualmente Identity Architect di Microsoft Corporation) sul suo sito http://www.identityblog.com . Questo confronto aperto con la comunità di esperti in ambito Identity Management ha prima esaminato i motivi dei fallimenti degli scorsi tentativi di raggiungere tale obiettivo, per poi focalizzarsi sulle caratteristiche che tale sistema ideale di identificazione deve possedere per poter ricevere il maggior consenso possibile da parte di tutte le parti in gioco (utenti, fornitori di servizi e di identità, industrie). Il risultato di tale dialogo multilaterale è stato sintetizzato in 7 requisiti, sinteticamente codificati in quelle che ora sono note come le “Laws of Identity” e consultabili sul sito di Kim.

I ruoli dell’IDMS

Gli attori in gioco in questa architettura sono i seguenti:

• Identity Providers: gli enti che posseggono le informazioni relative alle identità digitali degli utenti viste come collezione di un insieme di attributi (claims). Un esempio può essere rappresentato dall’Ufficio Anagrafe comunale in grado di poter rappresentare le nostre identità di cittadini attraverso una serie di attributi (nome, cognome, sesso, stato civile, data di nascita, indirizzo di residenza, etc.).
• Relying parties: sono tipicamente i siti web che richiedono le identità digitali per identificare, autenticare e autorizzare gli utenti prima di concedere l’accesso a beni e servizi online.
• Subjects: sono gli individui e le entità rappresentate online tramite un’identità digitale: utenti, aziende ed enti.

I componenti funzionali dell’IDMS

Per realizzare questa architettura di interoperabilità multi-piattaforma sono necessari i seguenti componenti funzionali:

• Claims-based Identities: identità digitali rappresentate da un insieme di attributi (claims) che qualificano il soggetto dell’identità. Tali “claims” sono singole informazioni in merito al soggetto che l’Identity Provider asserisce come vere. Nel caso in cui il soggetto e l’Identity Provider coincidano si parla di Self-issued identities, in cui è lo stesso soggetto che asserisce la validità delle informazioni a lui pertinenti.
• Negotiation: gli attori dell’IDMS ricorrono a questo meccanismo per concordare le caratteristiche della comunicazione in grado di connetterli tra di loro. Se una parte fosse in grado di fornire claims di tipo SAML e X.509, e l’altra solo Kerberos e X.509, ragionevolmente le parti negozieranno l’uso dei claims X.509 come metodo comune di dialogo.
• Encapsulating Protocol: per permettere alle parti di scambiarsi claims e requisiti in modo trasparente relativamente alle rispettive tecnologie è necessario l’uso di un protocollo di incapsulamento. In questo modo, per esempio, un’applicazione può ricevere claims di tipo SAML senza la necessità di capire e implementare il protocollo SAML.
• Claims Trasformers: sono i componenti che gestiscono l’interoperabilità tra i diversi sistemi di identità in quanto provvedono a tradurre i claims compresi da uno specifico sistema in claims in grado di essere compresi da un altro sistema. Questi componenti possono anche trasformare o rifinire la semantica dei claims (per esempio dall’informazione “nato il 1° gennaio 1968” produrre l’informazione “maggiorenne”), o semplicemente trasformare il loro formato.
• Consistent User Experience: l’obiettivo dell’IDMS è di abilitare l’utente a poter fare delle decisioni informate e ragionate relativamente al rilascio di informazioni pertinenti alle sue identità, tramite la realizzazione di una interfaccia utente che sia facile, intuitiva e consistente a prescindere dal sistema di identità in uso.

I protocolli dell’IDMS: WS-* Web Services

I requisiti dell’IDMS sono adeguatamente supportati dalle specifiche dell’architettura dei WS-* Web Services: sono specifiche pubblicate e liberamente disponibili, in parte già sottomesse o in procinto di esserlo agli organismi open standards per la certificazione, e tali da permettere l’implementazione esente da royalty. Alcuni di questi protocolli realizzano la vera e propria ossatura di base dell’IDMS:

• WS-Trust rappresenta il protocollo di incapsulamento
• Le negoziazioni sono fatte tramite WS-MetadataExchange e WS-SecurityPolicy

Per oggi credo possa bastare! Siete pronti per la 4a puntata ?