Introduzione a Windows CardSpace

 

David Chappell
Chappell & Associates

Aprile 2006

Si applica a:
   Windows CardSpace
   Windows Vista
   Windows XP
   Windows Server 2003

Riepilogo: Questo articolo presenta il set di nuove funzionalità di Windows denominate CardSpace, che offre una soluzione basata su standard per l'uso e la gestione di identità digitali diverse. (25 pagine stampate)

Contenuto

Informazioni sull'identità digitale
Elementi forniti da Windows CardSpace
Analisi delle schede informative
Interoperabilità con Windows CardSpace
Windows CardSpace e altre tecnologie Microsoft
Conclusione
Ulteriori informazioni

Informazioni sull'identità digitale

informazioni sull'utente È una domanda semplice, ma non ha una risposta semplice. Il modo in cui rappresenti i cambiamenti di identità mentre passi attraverso il mondo. Quando presenti il tuo passaporto all'Ufficio immigrazione di un aeroporto, sei un cittadino di qualche paese. Quando mostri la patente di guida a un poliziotto che ti ha fermato per la velocità, sei un conducente legale che risiede in qualche località. Quando si usa la carta di credito per pagare un romanzo più venduto in un booktore, si è un cliente con un numero di conto specifico. Diversi contesti richiedono identità diverse, ognuna delle quali è espressa in modo diverso e fornisce informazioni diverse.

Tutti questi contesti hanno un modo ben comprensibile per stabilire la propria identità. Eppure, in un contesto molto importante, il mondo in rete, l'identità è attualmente una cosa molto più confusa. Proprio come nel mondo fisico, tutti noi abbiamo una varietà di identità digitali, e sono espressi in modi diversi. Oggi, tuttavia, non esiste un modo coerente per gestire questo portfolio di identità digitali. Al contrario, siamo rimasti in difficoltà in un ambiente complesso, confuso e insicuro.

Tuttavia, saranno sempre necessari diversi tipi di identità digitali: nessuna identità singola sarà sufficiente. E la realtà è che queste identità saranno sempre fornite da una gamma di origini diverse, nessun singolo provider di identità sarà sufficiente, né. Ciò significa che la soluzione non è quella di imporre un unico sistema per l'identità digitale, ma piuttosto di trovare un modo coerente per usare più sistemi di identità digitale. Ciò che è necessario è un sistema di sistemi, un metasistema, incentrato sull'identità.

La realizzazione di questo metasistema di identità richiede una cooperazione. Nessuna singola organizzazione può imporre unilateralmente una soluzione. Fortunatamente, esistono standard di comunicazione indipendenti dal fornitore che possono essere usati per risolvere questo problema. In base a SOAP e XML, questi standard includono WS-Security, WS-Trust, WS-MetadataExchange e WS-SecurityPolicy. Usando queste tecnologie di servizi Web, è possibile definire un modo coerente per lavorare con qualsiasi identità digitale creata da qualsiasi origine, usando qualsiasi tecnologia di gestione delle identità.

Lavorare con altri utenti, Microsoft ha svolto un ruolo importante nella definizione di questo metasistema di identità basato su standard. Microsoft aggiunge anche nuove funzionalità a Windows per rendere il metasistema delle identità una realtà. Windows CardSpace, originariamente denominato "InfoCard", consente a qualsiasi applicazione Windows, incluse le tecnologie Microsoft, ad esempio la prossima versione di Internet Explorer e quelle create da altri utenti, di offrire agli utenti un modo comune per lavorare con le identità digitali. Parte di .NET Framework 3.0, CardSpace sarà disponibile per Windows Vista, Windows XP e Windows Server 2003 ed è prevista per essere rilasciata all'inizio del 2007.

Windows è un sistema operativo ampiamente usato, quindi Cardspace è una parte importante di rendere reale il metasistema di identità. Tuttavia, questa soluzione non può avere esito positivo, a meno che non venga implementata anche da altre organizzazioni. Di conseguenza, Microsoft incoraggia attivamente la creazione e l'uso di software che possono partecipare al metasistema di identità. L'obiettivo è consentire agli utenti di qualsiasi computer, eseguire qualsiasi sistema operativo, usare le identità digitali con la stessa facilità, in modo efficace e sicuro come oggi usano le proprie identità nel mondo fisico.

Descrizione dell'identità digitale

Come le identità nel mondo reale, le identità digitali sono disponibili in tutte le forme e dimensioni. Forse hai un account di posta elettronica con Yahoo, ad esempio, identificato da un indirizzo di posta elettronica. Potresti anche avere identità digitali con varie organizzazioni commerciali, ad esempio Amazon o eBay, insieme alle identità per siti come MySpace.com. Ognuna di queste è in genere identificata da un nome utente definito. Al lavoro potrebbe essere assegnata un'identità digitale dal datore di lavoro, identificata dall'account di accesso alla rete. Questa identità è probabilmente gestita da alcuni servizi directory, ad esempio Active Directory, ed è in genere utile solo entro i limiti della rete aziendale.

Proprio come nel mondo reale, esistono buoni motivi per usare identità digitali diverse in contesti diversi. È comune, ad esempio, associare informazioni diverse a ogni identità. Un'identità usata con Amazon potrebbe consentire l'accesso al numero di carta di credito, mentre una usata con MySpace.com non lo fa. Anche le regole per ottenere ogni identità sono diverse. Ottenere un'identità digitale in Amazon è semplice: è sufficiente creare un nome utente e una password. Ottenere un'identità digitale presso il datore di lavoro è probabilmente un po 'più difficile, poiché, almeno, richiede l'approvazione degli amministratori che gestiscono la rete aziendale.

Rappresentazione dell'identità digitale: token di sicurezza

Nonostante la loro diversità, tutte le identità digitali hanno una cosa importante in comune: quando vengono trasmesse in rete, ogni identità digitale è rappresentata da un certo tipo di token di sicurezza. Un token di sicurezza è solo un set di byte che esprime informazioni su un'identità digitale. Come illustrato nella figura 1, queste informazioni sono costituite da una o più attestazioni, ognuna delle quali contiene una parte delle informazioni totali trasmesse su questa identità. Un token di sicurezza semplice può includere solo un'attestazione contenente un nome utente, mentre una più complessa può includere attestazioni contenenti il nome, il cognome, l'indirizzo principale e altro ancora. I token di sicurezza per alcune identità digitali possono includere anche attestazioni che contengono informazioni riservate, ad esempio numeri di carta di credito.

Figura 1. Token di sicurezza

Con la maggior parte dei token di sicurezza, vengono fornite alcune informazioni per dimostrare che queste attestazioni appartengono realmente all'utente che li presenta. Un modo semplice (e attualmente molto comune) per eseguire questa operazione consiste nell'inviare una password insieme alle attestazioni. Un approccio più potente consiste nel firmare digitalmente tutte le attestazioni o parte delle attestazioni usando una chiave privata e quindi fornire la chiave pubblica corrispondente, ad esempio sottoposta a wrapping in un certificato. Tuttavia, i token di sicurezza che rappresentano le identità digitali in genere forniscono un tipo di prova che consente a un ricevitore del token di verificare che questo token rappresenti effettivamente la persona o l'organizzazione con tale identità.

Anche se l'idea di base di ogni token di sicurezza è la stessa, è una raccolta di attestazioni, una varietà di formati diversi viene usata oggi per rappresentare tali token. L'esempio più semplice è rappresentato solo da un nome utente rappresentato come stringa di testo, ma sono comuni anche formati più complessi, ad esempio certificati X.509 e ticket Kerberos. Nessuno di questi formati è stato progettato per consentire la trasmissione di un set arbitrario di attestazioni, tuttavia, qualcosa che è abbastanza utile per alcune identità digitali. I token creati usando il saml (Security Assertion Markup Language), uno standard creato dal gruppo di settore OASIS, consentono di farlo. In base al codice XML, è possibile usare SAML per definire i token di sicurezza che contengono qualsiasi set di attestazioni richiesto.

Tradizionalmente, le identità digitali sono state usate principalmente per l'autenticazione. I formati di token di sicurezza più comuni, ovvero nome utente, certificati X.509 e ticket Kerberos, riflettono questo aspetto, perché le informazioni che contengono sono in gran parte incentrate sull'autenticazione di un'identità. Ma perché le identità digitali non dovrebbero essere tanto utili quanto le identità reali? Ogni carta nel portafoglio riflette un certo tipo di identità, e ognuno contiene anche informazioni utili che alcune autorità asserzioni sono vere. Ad esempio, la patente di guida include il tuo nome, la tua età, forse la tua immagine e altre informazioni, tutti asserendo di essere corretti da parte di alcune organizzazioni governative. Un'identità digitale che ha espresso queste informazioni potrebbe essere utile per varie cose, come dimostrare che sei 21 o più vecchio, o che si indossano realmente occhiali. Analogamente, ogni carta di credito contiene un numero di carta e una data di scadenza insieme al nome. Proprio come queste schede sono utili nel mondo fisico, sarebbe anche utile creare un'identità digitale per ogni scheda che potrebbe essere usata per generare un token di sicurezza che contiene le attestazioni appropriate.

Anche se i token di sicurezza sono stati storicamente incentrati sulla trasmissione di informazioni di autenticazione, è importante rendersi conto che la nozione di identità digitale è più ampia di questa. In genere non si usano carte di credito per autenticarsi, ad esempio, ma le informazioni trasmesse da questa identità, ad esempio il numero di carta di credito, sono ancora preziose. In realtà, il termine token di sicurezza è un errore, poiché i token possono contenere informazioni che non hanno nulla a che fare con la sicurezza. Usando SAML o altri approcci, è possibile definire token di sicurezza che contengono praticamente tutte le informazioni desiderate. Le identità digitali possono ora diventare molto utili nel mondo in rete, come le molte identità usate nel mondo reale.

Uso dell'identità digitale: Windows CardSpace e il metasistema di identità

La vita sarebbe più semplice se una singola identità digitale, rappresentata con un unico formato di token di sicurezza, potesse essere usata per tutti gli elementi. Tuttavia, per le stesse ragioni per cui abbiamo identità diverse nel mondo fisico, abbiamo sempre identità diverse nel mondo digitale. La sfida consiste nel creare, usare e gestire queste diverse identità digitali in modo comprensibile ed efficace.

Questo è esattamente il problema risolto dal metasistema di identità. Invece di inventare un'altra tecnologia per la creazione e la rappresentazione delle identità digitali, il metasistema delle identità offre invece un modo coerente per lavorare con più identità digitali, indipendentemente dai tipi di token di sicurezza usati. L'uso di protocolli standard che chiunque può implementare in qualsiasi piattaforma, il metasystem delle identità consente l'acquisizione e l'uso di qualsiasi tipo di token di sicurezza per trasmettere l'identità.

Fornendo agli utenti un modo per selezionare le identità e altro ancora, Windows CardSpace svolge una parte importante nel metasistema delle identità. Questo documento descrive CardSpace e come si adatta al metasystem delle identità. L'obiettivo è quello di chiarire ciò che questa tecnologia offre e come funziona. Tenere presente, tuttavia, che questa descrizione è basata su una versione Beta del sistema. Come sempre, alcuni aspetti potrebbero cambiare prima della versione finale della tecnologia.

Informazioni su Windows CardSpace

Quattro aspetti di questa tecnologia sono i più importanti:

• Supporto per qualsiasi sistema di identità digitale
• Controllo utente coerente dell'identità digitale
• Sostituzione dell'account di accesso Web basato su password
• Miglioramento della fiducia degli utenti nell'identità delle applicazioni remote

In questa sezione viene descritto il modo in cui CardSpace, come parte del metasistema delle identità, fornisce ognuna di queste quattro cose.

Supporto per qualsiasi sistema di identità digitale

Le più identità digitali usate provengono da diverse origini e sono espresse in diversi modi. In altre parole, in genere ci si basa su diversi sistemi di identità digitale, ognuno dei quali può usare una tecnologia sottostante diversa. Per pensare a questa diversità in modo generale, è utile definire tre ruoli distinti:

• Utente: noto anche come soggetto, l'utente è l'entità associata a un'identità digitale. Gli utenti sono spesso persone, ma organizzazioni, applicazioni, computer e altre cose possono avere anche identità digitali.
• Provider di identità: un provider di identità è solo quello che suggerisce il nome: qualcosa che fornisce un'identità digitale per un utente. Per l'identità digitale assegnata dall'utente dal datore di lavoro, ad esempio, il provider di identità è in genere un sistema come Active Directory. Per l'identità digitale usata con Amazon, il provider di identità è efficace, poiché definisci il tuo nome utente e la tua password. Le identità digitali create da diversi provider di identità possono contenere informazioni diverse e fornire livelli diversi di garanzia che l'utente sia effettivamente chi dichiara di essere.
• Relying party: una relying party è un'applicazione che in qualche modo si basa su un'identità digitale. Una relying party userà spesso un'identità, ovvero le informazioni contenute nelle attestazioni che costituiscono il token di sicurezza dell'identità, per autenticare un utente e quindi prendere una decisione di autorizzazione, ad esempio consentire all'utente di accedere ad alcune informazioni. Una relying party può anche usare l'identità per ottenere un numero di carta di credito, per verificare che lo stesso utente lo acceda in momenti diversi o per altri scopi. Esempi tipici di relying party includono siti Web Internet, ad esempio siti di libri online e aste, e qualsiasi applicazione che accetta richieste tramite servizi Web.

Dato questi tre ruoli, non è difficile comprendere in che modo Windows CardSpace e il metasistema delle identità possono supportare qualsiasi identità digitale. La figura 2 mostra le interazioni fondamentali tra i tre ruoli.

Figura 2. Interazioni tra gli utenti, il provider di identità e i ruoli della relying party

Come suggerisce la figura 2, un utente potrebbe basarsi su un'applicazione che supporta CardSpace, ad esempio un Web browser, per accedere a una qualsiasi delle diverse relying party. Potrebbe anche essere in grado di scegliere da un gruppo di provider di identità come origine dell'identità digitale che presenta a tali relying party. Qualunque scelta faccia, lo scambio di base tra queste parti ha tre passaggi:

1. Prima di tutto, l'applicazione ottiene i requisiti del token di sicurezza della relying party a cui l'utente vuole accedere.

   Queste informazioni sono contenute nei criteri della relying party e includono elementi quali i formati del token di sicurezza che la relying party accetterà e esattamente le attestazioni che tali token devono contenere.

2. Dopo aver specificato i dettagli del token di sicurezza, questa relying party richiede, l'applicazione passa queste informazioni a CardSpace, chiedendogli di richiedere un token da un provider di identità appropriato.

3. Dopo aver ricevuto questo token di sicurezza, CardSpace lo fornisce all'applicazione, che lo passa alla relying party.

   La relying party può quindi usare questo token per autenticare l'utente o per altri scopi.

Questa visione generale illustra gli aspetti più importanti del processo. Essi includono quanto segue:

• Windows CardSpace e il metasystem identity sono completamente agnostici sul formato del token di sicurezza richiesto da un provider di identità e passato a una relying party. In effetti, CardSpace in genere non è nemmeno consapevole del formato in cui si trova questo token. A causa di questo, CardSpace può usare qualsiasi sistema di identità digitale, usando qualsiasi tipo di token di sicurezza, inclusi i nomi utente semplici, i certificati X.509, i ticket Kerberos, i token SAML o qualsiasi altra cosa. In questo modo CardSpace e il metasistema di identità devono essere usati insieme a qualsiasi tecnologia di identità digitale. Consente anche il plugging in sistemi di identità digitali che potrebbero essere visualizzati in futuro.

• Tutti gli scambi definiti dal metasystem identity e implementati da CardSpace vengono eseguiti usando protocolli aperti e pubblicati.

  Nello scenario più generale, i criteri di una relying party vengono descritti usando WS-SecurityPolicy, che i criteri vengono recuperati usando WS-MetadataExchange, un token di sicurezza viene acquisito usando WS-Trust e tale token viene trasmesso alla relying party usando WS-Security (tutto se i protocolli WS-* necessari per abilitare lo scambio sicuro di token di identità nel metasystem delle identità sono (o presto verranno inviati) ai corpi standard.

  Nello scenario più semplice (e probabilmente più comune) di un Web browser che interagisce con un sito Web, il criterio della relying party può essere espresso usando HTML e entrambe queste informazioni sui criteri e il token di sicurezza possono essere scambiate con il sito usando HTTPS. Anche se le interazioni con un provider di identità dipendono ancora da WS-Trust, un sito Web non è necessario implementare alcuna delle specifiche WS-* per agire come una relying party.

  In entrambi gli scenari, l'uso di CardSpace non richiede che le relying party o i provider di identità implementino protocolli proprietari.

Come indicato nella figura 2, CardSpace è utile solo se i provider di identità e le relying party implementano i protocolli usati dal metasystem identity. Mentre Microsoft ha portato lo sforzo di definire il metasystem e ha creato Windows CardSpace per fornire componenti metasystem chiave per Windows, lo sforzo non può riuscire senza partecipazione da altre organizzazioni.

Controllo utente coerente dell'identità digitale

La presenza di protocolli standard per l'acquisizione e la trasmissione di token di sicurezza è certamente utile. Tuttavia, senza alcun modo per consentire agli utenti di comprendere e prendere decisioni sensibili sulle identità digitali che rappresentano, il sistema comprimerebbe in complessità inutile. Di conseguenza, uno degli obiettivi principali di CardSpace e il metasistema delle identità consiste nel consentire agli utenti, da uno specialista di sicurezza, a tua madre e papà, di prendere decisioni valide sull'uso delle loro identità digitali.

A questo scopo, CardSpace implementa un'interfaccia utente intuitiva per l'uso delle identità digitali. La figura 3 mostra una rappresentazione della parte forse più importante di questa interfaccia, la schermata usata per selezionare un'identità.

Figura 3. Schermata di selezione dell'identità CardSpace

Come illustrato in questo screenshot, ogni identità digitale viene visualizzata come scheda informazioni, talvolta abbreviata in solo InfoCard (origine del nome codice della tecnologia). Ogni scheda rappresenta un'identità digitale che l'utente può potenzialmente presentare a una relying party. Insieme alla rappresentazione visiva visualizzata nello screenshot, ogni scheda contiene anche informazioni su una determinata identità digitale. Queste informazioni includono il provider di identità da contattare per acquisire un token di sicurezza per questa identità, il tipo di token che questo provider di identità può emettere e esattamente quali attestazioni possono contenere questi token. Come descritto più avanti, ogni scheda informazioni viene effettivamente creata da un provider di identità e quindi installata nel computer di un utente. Selezionando una scheda specifica, l'utente sceglie effettivamente di richiedere un token di sicurezza specifico con un set specifico di attestazioni creato da un provider di identità specifico. Questa complessità tecnica è nascosta, tuttavia, lasciando l'utente libero di pensare in termini che hanno senso per lui o per lei. Figura 4, una versione leggermente espansa della figura 2 mostra dove la decisione dell'utente si adatta al processo.

Figura 4. Selezione di un'identità

Come descritto in precedenza, il processo inizia con un'applicazione che richiede i criteri di una relying party. Tenere presente che questo criterio indica il tipo di token di sicurezza che questa relying party può accettare e quali attestazioni devono contenere tali token. Dopo che queste informazioni vengono restituite e passate a CardSpace, il sistema visualizza la schermata di selezione della scheda. Per offrire all'utente un'esperienza coerente, ogni scheda informativa che possiede su questo sistema viene visualizzata, proprio come ogni scheda in un portafoglio è visibile quando viene aperto il portafoglio. Solo alcune schede sono applicabili in qualsiasi situazione, tuttavia, e pertanto tutte le schede informazioni il cui token di sicurezza e le attestazioni associate non soddisfano i requisiti di questa relying party vengono disattivati, ovvero l'utente non può inviarli. Dopo che l'utente fa clic su una scheda specifica, CardSpace invia una richiesta, come descritto in precedenza, al provider di identità associato a tale scheda. Come in precedenza, il provider di identità restituisce quindi un token di sicurezza passato alla relying party.

Fornire un modo coerente per gli utenti di selezionare le identità digitali è importante per due motivi principali:

• Gli utenti hanno un modo coerente e prevedibile per usare le proprie identità digitali. Senza questo, per tutti gli utenti esperti, il risultato sarebbe sicuramente confusione e errore. Ogni applicazione creata per l'uso di CardSpace userà lo stesso meccanismo esatto per l'uso delle identità digitali, presentandole agli utenti tramite l'esatta stessa interfaccia.
• Gli utenti vengono schermati dalle differenze nelle tecnologie di sicurezza. Non è necessario prestare attenzione se un determinato token di sicurezza dell'identità è espresso usando certificati X.509, SAML o in altro modo. Fornendo una rappresentazione visiva comune, CardSpace assicura che gli utenti non si trovino a fronte di questa complessità non necessaria. Tutto è espresso in termini di ciò che un utente è interessato: l'identità stessa e le informazioni contenute.

Per una maggiore sicurezza, gli utenti possono scegliere di proteggere le singole schede informazioni con numeri di identificazione personali (PIN), richiedendo a un utente di immettere questo valore prima che venga usata la scheda informazioni. E per evitare ulteriori attacchi locali, CardSpace crea un desktop Windows privato per la schermata di selezione delle identità che consente agli utenti di scegliere una scheda. Questo è simile al meccanismo usato per isolare la schermata di accesso di Windows e impedisce attacchi da altri processi in esecuzione in locale.

Vale la pena sottolineare che fornire un meccanismo coerente per gli utenti per selezionare l'identità digitale da usare è una parte intrinseca del metasystem delle identità. Questo documento è incentrato su CardSpace, una tecnologia Windows, ma le implementazioni in altri sistemi operativi devono fornire la propria schermata intuitiva per la selezione di una scheda.

Sostituzione dell'account di accesso Web di Password-Based

Il tipo più comune di token di sicurezza su Internet oggi è solo un nome utente. Il modo più comune per dimostrare che un nome utente è davvero il tuo è fornendo la password associata. A volte il nome utente e la password vengono assegnati dal sito a cui si accede, anche se più comunemente si sceglie entrambi. Poiché i siti che eseguono questa operazione in genere usano SSL per comunicare con il browser, questo approccio è stato considerato ragionevolmente sicuro. SSL garantisce che l'intera comunicazione sia crittografata e pertanto gli utenti malintenzionati non possano rubare la password ascoltando la comunicazione.

Tuttavia, gli schemi basati su password come questo sono vulnerabili a un altro tipo di attacco: phishing. Inviando messaggi di posta elettronica ingannevoli, gli utenti malintenzionati tentano di ingannare gli utenti ad accedere a copie spurie di siti reali, rivelando le proprie password e forse altre informazioni personali. Se le password non fossero il meccanismo di autenticazione dominante sul Web, tuttavia, questo tipo di phishing sarebbe meno di una minaccia: non ci sarebbero password da rubare. Per rendere possibile questa operazione e per migliorare la sicurezza dell'accesso Web in generale, CardSpace consente di sostituire l'accesso Web basato su password con un meccanismo più efficace.

Invece di autenticare gli utenti con password, una relying party, ad esempio un sito Web, potrebbe invece autenticare gli utenti con token di sicurezza. Ad esempio, una società che fornisce una famiglia di siti Web potrebbe anche offrire un provider di identità, in esecuzione su un computer e accessibile da qualsiasi client, in grado di emettere token accettati da tutti i siti della famiglia. Questo approccio riduce al minimo l'uso delle password ed è certamente un'opzione che può essere usata con CardSpace. Tuttavia, è applicabile solo per un set specifico di siti, poiché non esiste un singolo provider di identità che tutti i siti Web accetterebbero per emettere token di sicurezza.

E cosa accade nel caso in cui gli utenti scelgano i propri nomi utente e password? Questo approccio è molto ampiamente usato dai siti Web oggi, in parte perché è semplice: non è necessario alcun provider di identità di terze parti. Non garantisce molto che l'utente sia realmente chi dichiara di essere, dal momento che il sito non può sapere se il nome fornito dall'utente è davvero il suo o il suo. Tuttavia, i siti che usano questo approccio in genere devono riconoscere un determinato utente ogni volta che accede. Tutto ciò richiede un'identità digitale univoca per l'utente, non necessariamente una che contiene informazioni vere su di lui o su di lei.

In breve, il problema è questo: una relying party vuole accettare i token di sicurezza creati da un provider di identità, perché in questo modo sarebbe possibile sostituire gli account di accesso basati su password che possono essere inseriti in phished. Nella maggior parte dei casi, tuttavia, non esiste un provider di identità di terze parti ampiamente accettato per creare questi token. Tuttavia, poiché l'obiettivo è solo riconoscere più accessi da parte dello stesso utente, non è necessaria un'identità digitale complessa.

Per risolvere questo problema, CardSpace include un provider di identità autocertificato. Come illustrato nella figura 5, questo provider di identità autocertificato viene eseguito nel sistema Windows locale e può produrre schede informative esattamente come qualsiasi altro provider di identità. Infatti, per distinguere i provider di identità esterni dalla varietà auto-rilasciata, i provider esterni vengono talvolta definiti provider di identità gestiti e le schede informative create sono note come schede gestite . Nell'esempio illustrato nella figura 5 l'utente ha tre schede acquisite da provider di identità esterni, insieme a una scheda acquisita dal provider di identità autocertificata.

Figura 5. Utente con una scheda informativa da un provider di identità autocertificato

Le schede informative create dal provider di identità autocertificata possono contenere solo informazioni di base, ad esempio il nome dell'utente, l'indirizzo postale, l'indirizzo di posta elettronica e il numero di telefono. Quando un utente sceglie di inviare una di queste schede a una relying party, il provider di identità autocertizionato nel sistema dell'utente genera un token SAML contenente le informazioni che l'utente ha inserito in questa scheda. Il provider di identità autofirmato genera anche una coppia di chiavi pubblica/privata, firmando il token di sicurezza con la chiave privata. Per impedire a un utente malintenzionato di riutilizzarlo, questo token contiene anche un timestamp e altre informazioni, rendendolo inutile a chiunque tranne l'utente originale. L'applicazione invia quindi questo token firmato, insieme alla chiave pubblica associata, alla relying party. La relying party può usare la chiave pubblica per convalidare la firma digitale del token di sicurezza, garantendo così che il token venga presentato dal proprietario legittimo. Per impedire alle relying party di riunirsi e tenere traccia delle attività di un utente confrontando la chiave pubblica dell'utente, il provider di identità autodemesso crea una coppia di chiavi diversa per ogni relying party a cui si accede con questa scheda (anche se questo dettaglio è nascosto all'utente, che vede solo una singola scheda informativa per questa identità).

L'idea principale è questa: perché i token di sicurezza emessi dalla maggior parte dei provider di identità, inclusi quelli creati dal provider di identità autocertificato di CardSpace, non usano password, relying party, inclusi siti Web e altri, possono usare questi token anziché le password per autenticare gli utenti. Se un sito non usa password, i phisher non possono ingannare gli utenti a rivelare tali password.

Il phishing è un problema serio. Se l'unico vantaggio di Windows CardSpace e del metasistema di identità consiste nel ridurre questo problema, essi avranno notevolmente migliorato il mondo online di oggi.

Maggiore attendibilità degli utenti nell'identità delle applicazioni Web

La riduzione della dipendenza dei siti Web dall'accesso basato su password consente di ridurre il dolore del phishing, ma non eliminerà il problema. Se un utente viene ingannato ad accedere al sito di phisher, tale sito potrebbe accettare qualsiasi token di sicurezza fornito dall'utente, autoemesso o altro, e quindi richiedere informazioni come un numero di carta di credito. Il phisher non acquisirà la password dell'utente per il sito che sta simulando, ma lui o lei certamente potrebbe imparare altre cose utili.

La radice del problema è l'impossibilità dell'utente di distinguere il sito reale per, ad esempio la sua banca, da un sito impostore messo in piedi da un phisher. Entrambi possono visualizzare gli stessi logo e altri elementi grafici. Entrambi possono anche usare SSL per proteggere la comunicazione, dal momento che i phisher possono acquisire certificati proprio come qualsiasi altro. Se un utente fa clic su un collegamento fornito nel messaggio di posta elettronica di un phisher, può trovarsi connesso a qualcosa che sembra proprio come il suo sito della banca. Il piccolo blocco nell'angolo inferiore destro di Internet Explorer potrebbe anche essere presente, a indicare che la comunicazione è protetta da SSL.

Per risolvere questo problema sono necessari due aspetti:

• Un modo più sicuro per un sito Web per dimostrare la propria identità agli utenti
• Un modo coerente per consentire agli utenti di conoscere il livello di garanzia offerto da un sito come prova della propria identità e quindi di prendere una decisione esplicita su se considerare attendibile il sito.

Windows CardSpace e il metasistema di identità risondono entrambi questi problemi.

Risolvere il primo problema, migliorando il modo in cui un sito Web può dimostrare la propria identità agli utenti, dipende dal miglioramento dei certificati usati per eseguire questa operazione. Oggi, un sito Web dimostra in genere la propria identità con il certificato usato per la comunicazione SSL. Questo è meglio di niente, ma i certificati SSL provano solo che un determinato sito ha un nome DNS specifico. Non esiste alcuna garanzia che questo nome DNS corrisponda alle informazioni visualizzate in tale sito. Un phisher potrebbe usare un certificato emesso per un nome DNS di cui è proprietario, ad esempio, per proteggere la comunicazione con un sito che è stato accuratamente creato per avere un aspetto simile alla banca. I certificati SSL non sono sufficienti per risolvere questo problema.

Per risolvere questo problema, Microsoft collabora con altri utenti del settore per creare un nuovo livello di certificato. Questo certificato può contenere più informazioni rispetto a un certificato SSL tradizionale, inclusi il nome, il percorso e il logo dell'organizzazione a cui è stato rilasciato. Questo certificato di garanzia più alta sarà anche una fonte più autorevole di informazioni perché è più difficile ottenere, richiedendo un accordo più forte con l'autorità che la rilascia. Sia i provider di identità che le relying party possono usare questo nuovo tipo di certificato per dimostrare le proprie identità agli utenti delle applicazioni CardSpace.

La creazione di certificati con garanzia superiore risolve il primo dei due problemi elencati in precedenza. In definitiva, tuttavia, un essere umano deve ancora prendere una decisione su quali siti si fida. CardSpace rende esplicita questa decisione, richiedendo a ogni utente di approvare l'uso di ogni provider di identità e relying party a cui desidera accedere. Quando una scheda informativa viene installata per la prima volta nel sistema dell'utente, una schermata chiede all'utente di verificare che sia disposto ad accettare i token di sicurezza creati dal provider di identità che ha emesso questa scheda. Analogamente, la prima volta che si accede a una relying party, ad esempio un sito Web, viene visualizzata una schermata che richiede all'utente di indicare la propria volontà di inviare informazioni sull'identità digitale. La figura 6 mostra un esempio di come la schermata visualizzata per il primo accesso di un utente a una relying party potrebbe avere un aspetto:

Figura 6. Schermata visualizzata la prima volta che si accede a un partner relying

Come illustrato in questo esempio, la schermata può includere il nome, la posizione, l'URL del sito Web e il logo dell'organizzazione la cui identità viene approvata ,ad esempio Overdue Media. Può anche includere il nome e il logo dell'organizzazione che hanno verificato queste informazioni (ad esempio VeriSign).

Per aiutare l'utente a prendere decisioni valide, ciò che viene visualizzato sullo schermo varia a seconda del tipo di certificato fornito dal provider di identità o dalla relying party. Se viene fornito il certificato con garanzia superiore descritto in precedenza, la schermata può indicare che il nome, la posizione, l'URL del sito Web e il logo dell'organizzazione sono stati verificati, come illustrato nella figura 6. Ciò indica a un utente che l'organizzazione merita una maggiore attendibilità. Se viene fornito solo un certificato SSL, la schermata indica che è garantito un livello di attendibilità inferiore. E, se viene fornito un certificato ancora più debole, o nessun certificato, la schermata indica che non c'è alcuna prova che questo sito in realtà è chi dichiara di essere. L'obiettivo è aiutare gli utenti a prendere decisioni informate sui provider di identità che potranno fornire loro identità digitali e quali relying party sono autorizzati a ricevere tali identità digitali.

Tutto questo solleva una domanda seria: questo aiuterà davvero l'utente medio di Windows? Qualcuno che non è informato sulla sicurezza distribuita, qualcuno che non sa cos'è un certificato, e non quali autorità di certificazione possono essere considerate attendibili, prendere decisioni migliori usando CardSpace? Almeno, fornire un'esperienza coerente e prevedibile per l'accesso ai nuovi siti dovrebbe essere utile. Ogni applicazione basata su CardSpace, inclusa la versione successiva di Internet Explorer, richiederà l'approvazione esplicita dell'utente per usare ogni provider di identità e relying party a cui accede con CardSpace. L'utente visualizzerà sempre le stesse schermate per questo e queste schermate forniranno indicazioni su quanto l'utente può avere la certezza che il sito sia chi si dichiara essere. Inoltre, un utente decide solo di considerare attendibile un sito la prima volta che si accede al sito. Gli accessi successivi, anche mesi dopo, non visualizzerà una schermata simile a quella illustrata nella figura 6. Se questa schermata viene visualizzata quando l'utente accede a un sito a cui si accede in precedenza, è una forte indicazione che in qualche modo è stato ingannato nell'accesso a un sito di phishing.

Uso di Windows CardSpace: scenari di esempio

Il modo più chiaro per comprendere in che modo CardSpace e il metasistema di identità possono essere usati consiste nell'esaminare alcuni esempi tipici. Pensate a cosa accade, ad esempio, quando si accede a un commerciante online, ad esempio una libreria Internet. Nel caso più semplice, nessuna identità digitale è coinvolta— chiunque può sfogliare i libri in offerta, senza dire al commerciante chi sono. Quando si tenta di effettuare un ordine, tuttavia, è necessario accedere, che richiede la fornitura di un'identità digitale. Oggi, è molto probabile che questa operazione venga eseguita immettendo un nome utente e una password, entrambi i quali sono stati scelti. Se questo commerciante online supporta anche CardSpace e il metasistema di identità, fornirà un'altra opzione per identificarsi: utilizzando una scheda informativa. Per consentire questo problema, il commerciante potrebbe avere un pulsante separato nella schermata di accesso che è possibile fare clic per accedere con una scheda informativa, invece di immettere il nome utente e la password.

Facendo clic su questo pulsante, il browser usa CardSpace per accedere a questo sito. Come di consueto, verrà visualizzata la schermata di selezione CardSpace e si sceglierà una delle carte per identificarsi con questo commerciante. È probabile (anche se non necessario) che la scheda informativa scelta in questo caso sia creata dal provider di identità autocertificata, ovvero quella creata manualmente. Poiché tutto il sito deve eseguire a questo punto è identificare l'utente come cliente univoco, questa semplice forma di identità digitale è sufficiente. Per pagare gli acquisti, è possibile immettere le informazioni sulla carta di credito e l'indirizzo postale su un modulo Web come di consueto.

In questo semplice scenario, CardSpace ha fornito un modo per accedere a un commerciante online senza usare una password. Questo è utile ed è un passo avanti per l'identità digitale su Internet. Tuttavia, è solo l'inizio del modo in cui è possibile usare l'identità digitale. Nel passaggio di pagamento di questo esempio, ad esempio, potrebbe essere possibile usare una carta informativa per inviare le informazioni sulla carta di credito al sito. Si supponga che l'azienda che emette la carta di credito offra un provider di identità che consente di richiedere una carta informativa corrispondente alla carta fisica. Invece di immettere le informazioni sulla carta di credito in un modulo Web, il sito offre in alternativa un pulsante nella schermata di pagamento che consente di fornire una carta informativa. Facendo clic su questo pulsante, il sistema visualizza la schermata di selezione CardSpace, consentendoti di scegliere tra tutte le carte che verranno accettate per il pagamento in questo sito. Facendo clic su una delle carte, CardSpace potrebbe contattare il provider di identità dell'autorità emittente di questa carta, ottenere un token di sicurezza contenente le informazioni sulla carta di credito e quindi presentarlo al commerciante online.

Come illustrato in questo esempio, le identità digitali non sono solo per dimostrare chi sei. Come le identità fisiche rappresentate dalle varie carte nel portafoglio, le identità digitali possono essere usate per effettuare pagamenti o per altri scopi. Si supponga, ad esempio, che l'organizzazione che rilascia le licenze di driver nella propria località abbia reso disponibile un provider di identità. È ora possibile avere un'identità digitale che consente di verificare una varietà di informazioni personali per qualsiasi relying party. Nel Stati Uniti, ad esempio, i clienti devono dimostrare che sono 21 o più anziani per acquistare vino. Un commerciante di vino online potrebbe richiedere ai suoi clienti di presentare la versione CardSpace della licenza del loro conducente, che include la data di nascita, forse accettando anche una versione cardSpace di una carta di credito per pagare il vino.

Questo provider di identità di licenza del conducente può anche fornire altri tipi di schede informative. Ad esempio, alcune persone potrebbero voler avere un modo per dimostrare che sono 21 o più recenti, senza rivelare il loro nome o altre informazioni di identificazione. Un provider di identità di licenza del conducente conosce l'età e così insieme a una scheda di informazioni contenente tutto sulla licenza, potrebbe anche offrire una scheda più semplice contenente niente di più dell'età. Per le persone qualificate, questo provider di identità potrebbe anche offrire una scheda informazioni che contiene solo un'asserzione che si è 21 o più recenti, evitando di rivelare qualcosa di potenzialmente sensibile come l'età. Anche se sono chiamate "identità digitali", non è necessario che contengano tutte le informazioni che possono essere effettivamente usate per identificare un determinato utente. Per molti usi, tutto ciò che è necessario è un modo per affermare un'attestazione, ad esempio 21 o versioni precedenti, che è supportato da un'autorità attendibile.

Esistono molti altri esempi del modo in cui è possibile usare Windows CardSpace e il metasistema delle identità. Un provider di servizi telefonici mobili potrebbe offrire una scheda informazioni che i suoi sottoscrittori possono usare per caricare gli acquisti online alla fattura telefonica. Un datore di lavoro può assegnare ai dipendenti più identità digitali, ognuna con la propria scheda informativa, per l'uso nella rete aziendale. Un'identità può essere usata per l'accesso normale, mentre un altro, forse rimosso di tutto, diversamente dal fatto che questa persona è un dipendente, potrebbe esistere esclusivamente allo scopo di apportare suggerimenti anonimi alla gestione aziendale. Così come le identità nel mondo reale trasportano informazioni diverse e vengono usate per scopi diversi, le identità digitali possono essere usate anche in diversi modi. L'obiettivo di CardSpace e il metasistema delle identità è quello di rendere possibile questo ampio uso.

Analisi delle schede informazioni

Dal punto di vista di un utente, una scheda informativa è la rappresentazione visiva di un'identità digitale che vede sullo schermo. Per CardSpace, tuttavia, una scheda informazioni è effettivamente un documento XML archiviato nel computer Windows dell'utente. Dato questo, è importante comprendere come vengono acquisite le carte e cosa contengono. Questa sezione esamina questi problemi e altri problemi.

Come vengono acquisite le schede informazioni

Ogni scheda informazioni viene creata da un provider di identità. Per il provider di identità auto-rilasciato, CardSpace offre uno strumento grafico che consente agli utenti di creare schede. Per altri provider di identità, che in genere verranno eseguiti in altri computer, un utente deve acquisire le schede appropriate in qualche modo, ad esempio tramite il sito Web del provider di identità o tramite un messaggio di posta elettronica inviato dal provider di identità. In che modo viene definito da ogni provider di identità, non è possibile acquisire schede informazioni.

Tuttavia, viene acquisita, ogni scheda (anche una creata dal provider di identità autofirmato) è firmata digitalmente dal provider di identità che l'ha emesso e viene fornito con il certificato del provider di identità. Questa firma viene usata per verificare l'identità del provider di identità stesso. Dopo che la scheda si trova nel computer dell'utente, facendo doppio clic viene visualizzata una schermata che consente all'utente di installare questa scheda nell'archivio CardSpace standard. Questo è anche quando l'utente deve approvare il provider di identità come origine per i token di sicurezza, come descritto in precedenza (anche se questa approvazione non è necessaria per le schede informative create dal provider di identità auto-emesso). Al termine dell'operazione, la scheda può essere usata per richiedere token di sicurezza.

Quali schede informazioni contengono

Il contenuto di una scheda informazioni aiuta gli utenti a scegliere in modo intelligente un'identità digitale. Consentono inoltre a CardSpace di corrispondere a una scheda ai requisiti di una relying party e di acquisire un token di sicurezza appropriato dal provider di identità che ha rilasciato questa scheda. Per raggiungere questi due obiettivi, ogni scheda informativa contiene quanto segue:

• Un file JPEG o GIF con l'immagine della scheda che l'utente vede sullo schermo, insieme al nome della scheda visualizzata a lui o alla sua.
• Uno o più tipi di token di sicurezza che possono essere richiesti da questo provider di identità, insieme a un elenco di attestazioni ognuna di tali token può contenere. Ciò consente a CardSpace di corrispondere ai criteri di una relying party con i provider di identità che possono creare token di sicurezza che soddisfano i requisiti della relying party.
• URL per uno o più endpoint in questo provider di identità a cui è possibile accedere per richiedere un token di sicurezza.
• URL che identifica un endpoint nel provider di identità da cui è possibile ottenere il relativo criterio. Come descritto nella sezione successiva, queste informazioni indicano anche a CardSpace come devono essere autenticate le richieste al provider di identità.
• Data e ora di creazione della scheda informazioni.
• Riferimento a CardSpace per la scheda, che è un identificatore univoco globale specificato come URI. Questo identificatore viene creato dal provider di identità che rilascia la scheda e viene passato al provider ogni volta che viene richiesto un token di sicurezza usando questa scheda.

È anche importante notare cosa non è in una scheda informazioni: dati sensibili relativi a questa identità. Ad esempio, una carta informazioni creata da un'azienda di carta di credito non contiene il numero di carta di credito dell'utente. Anche se questo tipo di informazioni sensibili potrebbe essere visualizzato come attestazione in un token di sicurezza creato da un provider di identità, viene sempre archiviato nel sistema del provider di identità. Quando viene inviato in un token di sicurezza, queste informazioni vengono in genere crittografate, rendendo inaccessibile sia agli utenti malintenzionati che a CardSpace. Il punto chiave è che le informazioni sensibili non sono mai contenute in una scheda informazioni e pertanto non vengono mai archiviate nel computer dell'utente. Se sceglie di scegliere, il proprietario di una scheda informazioni può usare CardSpace per visualizzare in anteprima le informazioni visualizzate in un token di sicurezza creato usando tale scheda. Queste informazioni verranno recuperate dal provider di identità che ha rilasciato la scheda quando l'utente chiede di visualizzarlo. Dopo la visualizzazione, le informazioni riservate vengono quindi eliminate dal sistema dell'utente.

Roaming con schede informazioni

Persone spesso vogliono presentare la stessa identità digitale da più computer. Molti di noi usano un computer al lavoro, un altro a casa, e un terzo mentre viaggiamo. Per consentire il roaming tra questi diversi computer, CardSpace offre una funzionalità di esportazione di schede . Questa opzione consente la copia di schede di informazioni in un supporto di archiviazione esterno, ad esempio una chiave USB. Le schede possono quindi essere installate in altri computer, consentendo a un utente di richiedere token di sicurezza dai provider di identità nello stesso modo, indipendentemente dal fatto che usi il computer domestico, il computer dell'ufficio o il computer portatile in una camera hotel. Per proteggere gli attacchi, le schede informative esportate vengono crittografate usando una chiave derivata da una frase pass-phrase selezionata dall'utente. Ciò garantisce che anche se il supporto di archiviazione è perso, solo qualcuno che sa che la frase pass-phrase può decrittografare le schede che contiene.

Esistono tuttavia scenari per i quali questa soluzione non è adatta. Si supponga di voler usare un'identità basata su CardSpace da un caffè Internet, ad esempio. Questa operazione richiede l'installazione delle schede informative sul sistema del caffè. Per usare le identità esistenti create usando un provider di identità self-managed, è necessario installare anche le chiavi associate a tali identità. L'inserimento di tutte queste informazioni in un computer pubblico condiviso non è una buona idea. Anche se la prima versione di CardSpace non si risolve in questo scenario, la possibilità di installare un archivio CardSpace e un provider di identità auto-emesso automaticamente sull'hardware basato su USB è previsto per il prossimo futuro. Una volta disponibile questa opzione, un utente sarà in grado di collegare questo dispositivo a un computer e quindi richiedere token di sicurezza direttamente da esso, senza installare schede informazioni o chiavi nel computer in uso.

Revoking Information Card

Un altro problema che CardSpace deve risolvere è la revoca. Dopo che un provider di identità ha rilasciato una scheda informativa a un utente, come può essere revocata la scheda? Nel caso più semplice, il provider di identità stesso potrebbe voler interrompere l'emissione di token di sicurezza in base a questa scheda. L'uso di questo provider di identità richiede una sottoscrizione a pagamento e l'utente non ha mantenuto i pagamenti. La revoca in questo caso è semplice: il provider di identità smette di rispettare le richieste di token di sicurezza effettuate con questa scheda. Ogni richiesta include un riferimento CardSpace univoco e pertanto è facile per il provider di identità identificare le richieste effettuate con le schede revocate.

Un caso leggermente più complesso è quando l'utente vuole revocare una scheda informazioni. Forse un utente malintenzionato ha rubato il portatile dell'utente, che contiene schede di informazioni installate rilasciate da provider di identità esterni. Come accennato in precedenza, ogni scheda informazioni può essere assegnata a un PIN che deve essere immesso ogni volta che viene usata la scheda. In questo caso, un utente malintenzionato non può usare le carte rubate a meno che non sappia anche il PIN per ogni utente. Inoltre, alcuni provider di identità potrebbero richiedere all'utente di immettere una password o usare una smart card ogni volta che viene richiesto un nuovo token di sicurezza con una determinata scheda informazioni. Per le schede che non dispongono di queste protezioni, l'utente dovrà contattare ogni provider di identità le cui carte sono state compromesse, informandole che le schede non devono più essere accettate. Come per l'acquisizione di carte, non c'è alcun meccanismo standard per farlo. Ogni provider di identità deve fornire una propria procedura per un utente per annullare una scheda informazioni in sospeso e quindi interrompere l'onore delle richieste effettuate con tale scheda.

Ma quali informazioni sulle schede informazioni create dal provider di identità auto-rilasciato? Nel caso di un portatile rubato, il provider di identità per queste carte è stato rubato, e quindi non c'è modo di dirlo per interrompere l'onore delle richieste. Questo è molto simile alla perdita di una password, dove l'unica soluzione consiste nel informare le organizzazioni che accettano questa password sulla sua perdita. Se le schede informative vengono perse insieme al provider di identità autodemesso che li ha creati, il proprietario dovrà annullare manualmente il proprio account in ogni relying party che accetta i token di sicurezza creati usando queste schede ora compromesse. CardSpace fornisce una funzionalità di cronologia schede che registra tutti i siti in cui è stata usata una scheda, quindi il proprietario di questo portatile rubato può usare una copia di backup delle sue schede per determinare quali siti devono essere contattati.

Interoperabilità con Windows CardSpace

Windows CardSpace fa parte di .NET Framework 3.0 e le applicazioni basate su di esso sono necessariamente applicazioni Windows. I selettore di identità compatibili con CardSpace vengono implementati in altre piattaforme e dispositivi, tuttavia, e i provider di identità e le relying party non devono essere applicazioni Windows. In questa sezione viene fornita una panoramica dei provider di identità e delle relying party da eseguire per usare le applicazioni Windows che usano CardSpace.

Creazione di un provider di identità

I provider di identità possono essere creati usando qualsiasi piattaforma di sviluppo, in qualsiasi sistema operativo. Tuttavia, ogni provider di identità deve eseguire quattro operazioni per lavorare con CardSpace:

• Deve essere in grado di creare schede informazioni compatibili con il formato di scheda definito da Microsoft e deve fornire un modo per ottenere queste schede agli utenti.
• Deve implementare un servizio token di sicurezza (STS), come definito dalla specifica WS-Trust. Basata su SOAP, questa specifica definisce un modo standard per richiedere un particolare tipo di token di sicurezza che contiene attestazioni specifiche da un servizio di sicurezza. Ogni provider di identità deve implementare almeno un servizio token di sicurezza, ma il servizio token di sicurezza può emettere token di sicurezza in qualsiasi formato. Non viene richiesto alcun tipo di token specifico. Anche se non è necessario, è consigliabile che il provider di identità supporti anche estensioni specifiche per WS-Trust definiti da Microsoft per il metasistema delle identità.
• Deve definire i criteri usando WS-SecurityPolicy e quindi consentire l'accesso a questo criterio tramite WS-MetadataExchange. Come descritto in precedenza, ogni scheda informativa contiene un endpoint da cui è possibile recuperare i criteri di un provider di identità. Questo passaggio è stato omesso nelle figure 2 e 4, ma prima che un'applicazione client richieda un token di sicurezza da un provider di identità, CardSpace chiede innanzitutto al provider di identità il proprio criterio.
• Deve indicare nei criteri come devono essere autenticate le richieste di token di sicurezza. Nella prima versione di CardSpace sono supportate quattro opzioni per l'autenticazione degli utenti in un provider di identità:

  • Nome utente/password (che potrebbe richiedere all'utente di immettere una password per questo provider di identità ogni volta che viene usata una scheda)

  • Ticket Kerberos

  • Certificati X.509 v3 (basati su software o da smart card)

  • Token di sicurezza SAML creati da un provider di identità autocertificato.

    Un provider di identità può scegliere di supportare una o tutte queste opzioni.

Come parte dei criteri, un provider di identità può anche indicare che l'identità della relying party deve essere fornita quando un utente richiede un token di sicurezza per tale relying party. Per impostazione predefinita, l'identità della relying party non viene visualizzata da CardSpace a un provider di identità quando viene richiesto un token. In questo modo si protegge la privacy dell'utente, perché impedisce al provider di identità di conoscere il servizio a cui l'utente intende accedere con questo token. Tuttavia, alcuni provider di identità potrebbero richiedere la conoscenza dell'identità della relying party prima di emettere un token richiesto. Un server Kerberos, ad esempio, deve conoscere l'identità del servizio a cui accederà il client per creare un ticket per tale servizio. Più in generale, un'organizzazione che stabilisce un provider di identità per l'uso da parte dei propri siti Web potrebbe consentire solo al provider di identità di rilasciare token di sicurezza da usare con tali siti. Non sarebbe consentito usare questo provider di identità per scopi propri.

CardSpace definisce anche alcuni errori SOAP che possono essere inviati in caso di errori. Ad esempio, l'accesso a un provider di identità potrebbe generare errori che indicano che la scheda informazioni a cui si fa riferimento in una richiesta di token di sicurezza non è valida o è scaduta o che il provider di identità non è riuscito a creare un token di sicurezza contenente le attestazioni richieste.

Creazione di una relying party

Come i provider di identità, le relying party possono essere create usando qualsiasi piattaforma di sviluppo, in qualsiasi sistema operativo. Analogamente ai provider di identità, le relying party devono eseguire alcune operazioni per lavorare con CardSpace. I requisiti per una relying party sono:

• Deve essere in grado di accettare token di sicurezza. L'approccio più generale consiste nell'implementare WS-Security, ma un sito Web può anche accettare token inviati tramite HTTP.
• Deve definire la sua politica. Anche in questo caso, l'opzione più ampia consiste nell'usare WS-SecurityPolicy e quindi consentire l'accesso ai criteri tramite WS-MetadataExchange. Un sito Web può anche descrivere i criteri in HTML e trasmetterlo tramite HTTP.
• Deve rendere disponibile il certificato. Per una relying party che implementa le specifiche WS-*, questa operazione viene eseguita usando un'estensione definita da Microsoft per il riferimento all'endpoint WS-Addressing. Aggiungendo un elemento Identity al WS-Addressing EndpointReference, questa estensione offre un modo standard per esporre il certificato della relying party ai client.

Le relying party sono libere di accettare qualsiasi tipo di token di sicurezza. Anche se non è obbligatorio, molte relying party accetteranno i token di sicurezza prodotti dal provider di identità autocertificato di CardSpace. Microsoft definisce un valore specifico che una relying party può inserire nei criteri per indicare il supporto per questi token. Indipendentemente dai token di sicurezza accettati da una relying party, è possibile eseguire il mapping di queste informazioni in un'identità locale, convertendo, ad esempio, un token SAML in un SID (Windows Security Identifier) o un identificatore utente UNIX (uid).

Come per i provider di identità, CardSpace definisce alcuni errori SOAP che possono essere inviati se si verificano errori durante le interazioni dei servizi Web con una relying party. Ad esempio, l'accesso a una relying party potrebbe generare un errore che indica che una delle attestazioni nel token di sicurezza non è valida o che manca un'attestazione richiesta.

Windows CardSpace e altre tecnologie Microsoft

Come la maggior parte delle nuove offerte Microsoft, CardSpace avrà un impatto su altre parti del mondo Di Windows. Le tecnologie più importanti interessate da questo nuovo approccio all'identità digitale sono Internet Explorer (IE), Windows Communication Foundation (WCF), Active Directory e Windows Live ID. In questa sezione viene esaminato il modo in cui ognuno è correlato a CardSpace.

Windows CardSpace e Internet Explorer

La prossima versione del Web browser Microsoft, Internet Explorer 7, consentirà agli utenti di affidarsi a CardSpace per le proprie identità digitali. Poiché è lo strumento più diffuso di oggi per l'accesso a Internet, Internet Explorer è un'applicazione importante per questa nuova tecnologia di gestione delle identità. Nel caso più generale, CardSpace comunica interamente usando protocolli basati su SOAP. Come descritto in precedenza, tuttavia, i siti Web possono anche interagire con Internet Explorer 7 (e potenzialmente con altri Web browser) usando HTML e HTTP.

La figura 7 illustra un approccio per eseguire questa operazione.

Figura 7. Windows CardSpace e Internet Explorer 7

1. Il processo inizia quando un utente del browser accede a una pagina protetta in un sito Web, ad esempio la pagina per acquistare prodotti presso un commerciante online. A questo punto, il sito Web richiede che l'utente accinga al sito, quindi il sito reindirizza il browser alla relativa pagina di accesso.

2. Questo reindirizzamento comporta l'invio di un modulo di accesso al browser nel sito.

   Questo modulo potrebbe consentire all'utente di accedere al sito specificando il proprio nome utente e la password, come di consueto, ma se il sito supporta gli account di accesso CardSpace, la pagina che trasmette il modulo conterrà anche un tag OBJECT o una sintassi XHTML specifica. Queste informazioni contengono i criteri del sito e causeranno che il browser visualizzi un'opzione di accesso di Windows CardSpace all'utente.

3. Se l'utente seleziona questa opzione, Internet Explorer 7 eseguirà il codice identificato dal tag OBJECT o dalla sintassi XHTML che richiede il coinvolgimento di CardSpace nel processo di accesso.

4. Verrà visualizzata la schermata CardSpace e l'utente può selezionare un'identità.

5. Finora, tutte le comunicazioni con questo sito hanno usato HTTP. Quando l'utente seleziona un'identità, tuttavia, CardSpace contatta il provider di identità associato usando WS-Trust, come di consueto, e ottiene un token di sicurezza.

6. Questo token viene quindi inviato al sito Web usando HTTP POST come parte del processo di accesso.

   L'applicazione Web può usare il token per autenticare l'utente o per qualsiasi altro scopo.

In questo scenario, il provider di identità potrebbe essere il provider di identità autofirmato in esecuzione localmente nel sistema dell'utente o potrebbe trattarsi di un provider esterno. Il sito Web stesso può anche fornire il proprio servizio token di sicurezza che genera token personalizzati usati da questo sito. Questa opzione può essere utile per i siti che desiderano fornire token specifici dell'applicazione o per siti con traffico elevato, poiché consente la maggior parte del lavoro di autenticazione nei server dedicati.

Un aspetto più importante da fare su questo processo è che non c'è nulla di specifico di Internet Explorer. Qualsiasi browser, qualsiasi sistema operativo, può usare il metasistema di identità nello stesso modo. In Windows, l'obiettivo dichiarato di Microsoft è consentire a qualsiasi applicazione, inclusi i Web browser di altri fornitori, di gestire e usare le identità digitali con CardSpace.

Windows CardSpace e Windows Communication Foundation

Windows Communication Foundation è la prossima piattaforma Microsoft per la creazione di applicazioni orientate ai servizi. WCF implementa tutti i protocolli interoperabili usati da CardSpace e dal metasistema delle identità, tra cui WS-Security, WS-SecurityPolicy, WS-Trust e WS-MetadataExchange e gran parte di CardSpace stesso è basata su WCF. In modo imprevisto, l'uso di WCF per creare un'applicazione che funge da relying party, un provider di identità o un client CardSpace è semplice.

Per comprendere come viene eseguita questa operazione, è necessario conoscere alcuni aspetti relativi ai servizi WCF (che implementano operazioni) e ai client WCF (che richiamano tali operazioni). Ogni servizio WCF espone uno o più endpoint tramite cui è possibile accedere alle operazioni del servizio. Ogni client WCF indica l'endpoint con cui desidera comunicare. Sia il servizio che il client specificano un'associazione per un endpoint; l'associazione definisce il protocollo che verrà usato per trasmettere messaggi SOAP, come verrà eseguita la sicurezza e altro ancora. Ad esempio, l'associazione denominata WsHttpBinding indica che i messaggi SOAP devono essere inviati tramite HTTP, che WS-Security è supportato e altro ancora. WCF crea automaticamente anche una descrizione accessibile dei criteri di un'applicazione, espressa usando WS-SecurityPolicy.

Anche se non è certamente necessario, la maggior parte delle persone che implementano provider di identità e relying party nei sistemi Windows che supportano la versione 3.0 di .NET Framework li creerà probabilmente usando WCF. Per creare un provider di identità o una relying party, è sufficiente creare un servizio WCF conforme ai requisiti elencati nella sezione precedente. Se l'applicazione è conforme a questi requisiti e sceglie un'associazione WCF appropriata, ad esempio WsHttpBinding, può partecipare a CardSpace.

Tuttavia, la creazione di un'applicazione client WCF che consente all'utente di basarsi su CardSpace per specificare un'identità digitale richiede direttamente l'uso del software CardSpace. Viene fornita un'associazione speciale per indicare che un'applicazione WCF deve usare CardSpace per l'autenticazione. Se un client WCF specifica questa associazione per l'endpoint con cui comunica (un endpoint implementato da una relying party che può o meno essere compilato in WCF), CardSpace verrà richiamato automaticamente quando è necessario un token di sicurezza. Come di consueto, verrà visualizzata la schermata di selezione CardSpace, consentendo all'utente di scegliere l'identità digitale da inviare. CardSpace contatterà automaticamente il provider di identità appropriato per acquisire un token di sicurezza e quindi inserirlo nella richiesta in uscita dell'applicazione WCF. Lo sviluppatore specifica solo che l'associazione corretta deve essere usata e CardSpace si occupa di tutto il resto.

Windows CardSpace e Active Directory

Active Directory è un candidato ovvio e importante per un provider di identità. CardSpace è pianificato per il rilascio all'inizio del 2007, tuttavia, mentre non è pianificata alcuna nuova versione di Active Directory fino a un certo periodo di tempo dopo. Microsoft ha detto che Active Directory sarà finalmente in grado di agire nel ruolo di un provider di identità, ma non sono state annunciate date per quando questa funzionalità sarà disponibile.

Una domanda più immediata è il modo in cui CardSpace si riferisce a Active Directory Federation Services (ADFS). ADFS è attualmente disponibile e inizialmente può sembrare simile a CardSpace. Tuttavia, queste due tecnologie sono molto diverse. CardSpace fornisce un selettore di identità e un provider di identità autocertizionato, entrambi eseguiti in un computer client. ADFS è un software basato su server che consente a un'organizzazione di usare Active Directory per la federazione delle identità con altre organizzazioni tramite WS-Federation. Un'altra distinzione importante è che, mentre un browser che usa CardSpace svolge un ruolo attivo, come descritto nella sezione precedente, i browser sono oblivious ad ADFS, il loro ruolo è completamente passivo. Sebbene entrambi siano interessati all'identità, CardSpace e ADFS eseguono funzioni molto diverse.

Windows CardSpace e Windows Live ID

Il sistema Microsoft Windows Live ID (precedentemente noto come Passport) è stato originariamente progettato per fornire un sistema di autenticazione standard che può essere usato da qualsiasi sito su Internet. Oggi, la rete che si è evoluta da questo impegno iniziale è costituita in gran parte da siti gestiti da Microsoft stesso. Anche se Windows Live ID ora gestisce quasi un miliardo di accessi al giorno, la lezione era chiara: nessuna singola organizzazione, nemmeno una grande quanto Microsoft, poteva fungere da unico provider di identità per tutto su Internet.

CardSpace e il metasistema delle identità, con una visione molto più generale dei provider di identità e identità, rappresentano un approccio fondamentalmente diverso. Microsoft ha detto che Windows Live ID verrà modificato in modo da fungere da provider di identità e che gli utenti potranno accedere ai propri account Windows Live ID usando CardSpace. Tuttavia, CardSpace non ha alcuna dipendenza da Windows Live ID e il provider di identità fornito da Windows Live ID un giorno non avrà alcun ruolo speciale nel metasistema di identità.

Conclusione

I problemi risolti dal metasistema di identità sono indubbiamente importanti, come sono le soluzioni offerte. Fornire un modo standard per lavorare con identità digitali diverse può rendere il mondo in rete più comodo e sicuro come il mondo fisico. Dare agli utenti il controllo sull'identità usata in ogni situazione mette le persone al posto del modo in cui vengono usate le identità digitali. L'uso di identità digitali, incluse le identità auto-rilasciate, può ridurre la necessità di account di accesso Web basati su password e, insieme a una maggiore attendibilità degli utenti nell'identità di un sito Web, può anche ridurre gli attacchi di phishing che causano molti utenti.

Windows CardSpace è una parte fondamentale di queste soluzioni. Tuttavia, fino a quando le persone che creano software per altri sistemi operativi, creano provider di identità e forniscono relying party implementano anche i protocolli di servizi Web standard che consentono l'esistenza e l'interoperabilità di questo metasistema, lo sforzo non avrà ancora raggiunto i suoi obiettivi. Microsoft sta facendo parte fornendo software per Windows, ma non può rendere la visione del metasistema di identità con successo. Altri devono anche comprendere i vantaggi che deriveranno dall'uso più efficace delle identità digitali e devono scegliere di partecipare.

È comunque probabile che CardSpace sia ampiamente disponibile. Poiché il metasistema di identità sottostante CardSpace si basa su protocolli aperti, il software compatibile con CardSpace per i provider di identità, le relying party e altri selettori di identità possono essere creati su qualsiasi piattaforma o dispositivo. E poiché CardSpace espone un'interfaccia singolare e intuitiva, può essere usata in modo prevedibile e coerente da qualsiasi software Windows. Dato tutte queste realtà, Windows CardSpace è sicuramente importante per chiunque sia interessato all'identità digitale.

Ulteriori informazioni

Articoli

Le leggi dell'identità

Visione di Microsoft per un metasistema di identità

Siti

Windows CardSpace Developer Center

Blog

• Kim Cameron's Identity Weblog
• Weblog InfoCard di Andy Harjanto

 

Informazioni sull'autore

David Chappell è principal di Chappell & Associates a San Francisco, California. Attraverso la sua conversazione, la scrittura e la consulenza, aiuta i professionisti tecnologici di tutto il mondo a comprendere, usare e prendere decisioni migliori sul software aziendale.