Windows LiveID e WS-Federation: la base per un mondo S+S
Una delle più interessanti possibilità di Internet che oramai diamo per scontato è rappresentata dal fatto di avere un unico protocollo di rete unificato che , di fatto, garantisce la possibilità a qualunque macchina di poter colloquiare con qualunque altra macchina collegata alla rete. Anche a livello di applicazioni, la standardizzazione del Web e dei suoi protocolli come meccanismo di esposizione e condivisione di informazioni ha reso possibile la costruzione di una enorme quantità di applicazioni e di siti , raggiungibili attraverso modalità completamente standardizzate. Uno degli aspetti che resta ancora complesso e che comporta una notevole difficoltà nell'integrazione tra i siti e nell'utilizzo delle risorse esposte su Internet è rappresentato dagli aspetti collegati alla sicurezza . Siamo ancora in presenta di una ampia gamma di differenti modalità di autenticazionzione ed autorizzazione, non integrabili tra loro con semplicità, che costringento utenti ed applicazioni a gestire differenti modalità di autenticazione, impedendo di fatto la semplice costruzione di applicazioni che possano condividere e aggregare servizi offerti da siti differenti, frenando la possibilità di far evolvere Internet in una vera e propria piattaforma applicativa. Per materializzare la visione del Sofware + Service e rendere di fatto Internet una piattaforma di servizi componibili con il software locale alle nostre reti aziendali o di altri siti o servizi web, o direttamente utilizzabile on line come servizio, avere una piattaforma comune per i meccanismi di sicurezza e autorizzazione costituisce un vincolo di base.
Tra le princiopali iniziative portate avanti da un ampia gamma di vendor tra cui spiccano Microsoft ed IBM, per risolvere questa problematica ci sono le proposte di standard collegate a WS-Security. Per quanto riguarda Microsoft oltre alla collaborazione negli enti di standardizzazione per la proposizione degli standard , l'obiettivo degli ultimi anni è stato quello di lavorare in tutti i prodotti, tecnologie e servizi per applicare realmente gli standard proposti. In particolare nell'area dell'identity management un ampia iniziativa è stata messa in campo con l'identity metasystem e le sue 7 leggi fondamentali che per l'appunto mirano a garantire il massimo dell'interoperabilità e della semplicità di utilizzo da parte degli utenti di questi aspetti che sono fondamentali per garantire la possibilità di far evolvere Internet in una vera e propia piattaforma applicativa. Una componente importante della piattforma di servizi è rappresentata da Window Live Id che fornisce la base per i meccanismi di Autenticazione ed Autorizzazione per l'intera piattaforma di servizi on line di Microsoft e dei siti affiliati.
In un precedente post ho illustrato gli elementi fondamentali per poter agganciare l'autenticazione di Windows LiveID ad un nostro sito web utilizzandolo come provider di autenticazione. Nel post avevo anche indicato la possibilità ed il supporto di questo servizio ai meccanismi di federazione con altri sistemi di autenticazione attraverso WS-Federation , passo importante per materializzare il Digital Identity Metasystem , ed ho ricevuto una serie di richieste di approfondimento su questo aspetto da molte persone. WS-Federation è uno standard per permettere la federazione di sistemi di autenticazione differenti , consentendo di semplificare l'integrazione delle funzioni di autenticazione ed autorizzazione tra applicazioni e servizi che sono di aziende differenti o che comunque utilizzano differenti meccanismi e servizi di per gli aspetti di accesso, permettendo di implementare meccanismi di single sign-on tra sistemi di autentizione eterogenei .
WS-Federation pervede due profili: il profilo che prevede l'autenticazione di client Web di tipo Browser che viene genericamente indicato come profilo passivo ed il profilo attivo in cui abbiamo dei client di tipo diverso dal browser (smart client ) che accedono a dei web service che richiedono una autenticazione. Il profilo passivo di WS-Federation (quello riferito all'accesso via browser alle applicazioni Web) è anche supportato direttamente da active directory da Windows 2003 R2 in poi con gli Active Directory Federation Service che permettono la federazione di un dominio windows con altri sistemi che supportano lo stesso standard.
Windows Live ID è un Identity Provider nell'accezione prevista da WS-Trust e WS-Security. I siti ed i web service che vogliono utilizzare Windows Live ID come provider di autenticazione vengono genericamente indicati come Resource Provider (RP). Tutti i siti ed i servizi offerti da Microsoft utilizzano Windows Live ID come provider di autenticazione ed è possibile per qualunque sito o servizio Intenet, utilizzare Windows Live ID come provider di autenticazione, senza la necessità di condividere le informazioni di profilo degli utenti con il servizio. Nel momento in cui un client richiede una risorsa offerta da un resource provider che utilizza Live Id come provider di autenticazione , il client viene rediretto sul servizio di Live Id che provvede a verificare e credenziali del client chiamante ed a fornire le informazioni necessarie per accedere al servizio. Come abbiamo visto nel post precedete Live Id supporta la protezione di resource provider web sia nel caso di accesso da parte di client di tipo Browser che accede ad un sito web protetto sia il caso di smart client che accedono ad un web service. Le informazioni sull'integrazione dei due tipi di scenario sono contenute rispettivamente nel Web Client SDK e nel Smart Client SDK. Schematizzato ad alto livello il processo di autenticazione può essere rappresentato come di seguito:
1- Il client richiede accesso al Resource Provider
2- il client viene rediretto sull'Identity Provider e gli viene fornito un "security token" per l'accesso al resource provider
3- Il client torna dal resource provider presentando il security token, ottenendo l'accesso
Attraverso la federazione è possibile gestire lo scenario in cui Windows Live Id si integra con un altro Identity Provider (IP), permettendo di realizzare una "relazione di fiducia" (Trust) tra i due IP che permetta di rimappare l'identità autenticata da un IP su un' identità gestita dall'altro. A seconda delle necessità e degli accordi il Trust pò essere effettuato in modo unidirezionale o bidirezionale. Con questo scenario un utente che ha le credenziali per autenticarsi su un IP , per accedere alle risorse protette da un altro IP può farlo senza la necessità di creare e gestire una nuova identità presso il secondo IP. Cerco di chiarire questa possibilità con un esempio. Proviamo ad immaginare un ipotetico sito Internet alfa.com che dispone già di un suo IP che è ingrado di autenticare gli utenti che accedono al sito che verranno identificati come nomeutente@alfa.com . Il sito alfa.com vuole introdurre alcuni controlli di Windows Live e integrarli all'interno delle pagine del sito e vuole fare in modo che gli utenti che sono già autenticati dal suo IP non debbano inserire le credenziali di Windows Live ID per accedere ai servizi, ma possano essere direttamente riconosciuti con le credenziali di alfa.com anche quando, ad esempio, accedono alla cassetta postale su Windows Live Mail . La federazione e lo standard WS-Federation rendono possibile proprio la gestione di questo tipo di scenari facendo in modo che le credenziali autenticate da un IP possano essere rimappate su un altro IP.
Lo scenario non si limita ovviamente ad un sito, ma è possibile ad esempio federare direttamente l'identity provider di un azienda con Live Id garantendo la possibilità per questa azienda di integrare le sue applicazioni con i servizi di Microsoft ottenendo un modello di sicurezza affidabile ed omogeneo con estrema semplicità, senza costringere gli utenti a gestire differenti identità. Ad esempio gli utenti interni potrebbero avvalersi di Windows Live Mail utilizzando direttamente le credenziali con cui si collegano alla rete interna, senza doversi autenticare nuovamente con credenziali diverse per accedere a questi servizi. Gli utenti della Intranet potrebbero usare alcune funzionalità di Office Live , senza doversi riautenticare, e così via per tutti gli altri servizi che sono disponibili nell'offerta online, rendendo di fatto possibile materializare la visione di internet come piattaforma che può essere combinata con i software locale alle reti ad al device client.
Nel caso del nostro sito di esempio alfa.com immaginiamo di avere un utente che si collega direttamente alla sua e-mail su Windows Live mail. Il resource provider di Live Mail non riconosce l'utente e lo indirizza verso l'IP di Windows Live ID , responsabile del riconoscimento degli utenti per il sito di Live Mail. All'utente viene presentata l'interfaccia per l'autenticazione e l'utente ha la possibilità di selezionare un differente IP specificando il suo nome di utente numeutente@alfa.com . A questo punto Windows Live ID redirige la richiesta sul provider di autenticazione con cui è federato di alfa.com dove l'utente può essere autenticato con il meccanismo previsto da alfa.com. Ottenuta l'autenticazione , la richiesta torna su Windows Live Id che estrae e verifica il security token rilasciato da alfa.com e cifrato con la chiave privata del certificato digitale di alfa.com e la rimappa su un utente Windows Live Id, rilasciando il security token opportuno con cui il browser client attraverso una redirect si ripresenta da Windows Live Mail , ottenendo l'accesso.
1- Il client richiede l'accesso ad una risorsa su Windows Live ID
2- Viene rediretto su Live Id e viene presentata l'interfaccia per l'autenticazione e l'utente ha la possibilità di selezionare un differente IP specificando il suo nome di utente numeutente@alfa.com
3- La richiesta viene rediretta su alfa.com dove l'utente può essere autenticato con il meccanismo previsto da alfa.com
4 - La richiesta viene rediretta su Windows Live ID che estrae e verifica il security token rilasciato da alfa.com e cifrato con la chiave privata del certificato digitale di alfa.com e la rimappa su un utente Windows Live Id, rilasciando il security token opportuno
5- client attraverso una redirect si ripresenta da Windows Live Mail , ottenendo l'accesso.
Abbiamo schematizzato il comportamente in caso di client Browser (profilo passivo ) , un approccio simile si realizza anche nel caso di profili attivi ovvero smart client che accedono a Web Service.
Per chi volesse approfondire l'argomento segnalo un articolo pubblicato di recente su MSDN che introduce le possibilità di federazione di LiveId: Windows Live ID Federation da leggere dopo il documento di