Windows Identity Foundation - Indroduzione allo sviluppo

Windows Identity Foundation
Indroduzione allo sviluppo
                                                                                                    di Luca Cestola

Dopo una panoramica a livello teorico, entriamo nel vivo della programmazione, cominciando con un primo
semplice esempio di utilizzo della modalità di autenticazione passiva. Vediamo come le nostre applicazioni web
possano sfruttare le capacità di WIF per abilitare scenari di tipo Single Sign On e Identity Management.

Autenticazione passiva
Per una panoramica sugli aspetti teorici, rimando all'articolo precedente mentre qui facciamo solo un breve
riepilogo dei concetti che sono alla base della modalità passiva, ovvero quella utilizzata in contesti web-
oriented, dove il client è il nostro browser.
Abbiamo visto come la componente STS (Secure Token Service) si occupi di creare un token firmato contenente
un set di Claim, che verrà utilizzato dal nostro sito (Relying Party) per autenticare l'utente. Questa componente
può essere disponibile sotto forma di web service o di pagina web. Nel caso di uno scenario di tipo passivo è
sufficiente, ed anche utile, che sia disponibile sotto forma di pagina web.

Il meccanismo è il seguente:

      l'utente vuole accedere all'applicazione e indirizzerà il browser ad una pagina del nostro sito
      La nostra applicazione verificherà, tamite un modulo messo a disposizione da WIF, se l'utente è già in
       possesso di un token valido per accedere e nel caso lo sia, provvederà ad autenticare l'utente e
       mostrerà la pagina o il contenuto richiesto.
      Se l'utente non è in possesso di un token valido, il browser verrà rediretto verso la pagina di
       autenticazione fornita dal STS informandolo, normalmente tramite un parametro nell'url, di quale sia
       il RP al quale si vuole accedere.
      Il STS presenterà all'utente una pagina di richiesta delle credenziali necessarie al nostro RP per
       consentire l'accesso ed in caso di login corretto produce un cookie contenente il token firmato ed il
       browser viene nuovamente rediretto alla pagina di provenienza.

WIF riduce in modo significativo la quantità di codice necessaria per gestire questo scenario e Visual Studio ci
viene in aiuto anche per quanto riguarda la parte di configurazione. Per consentire un'introduzione soft alla
tematica, analizzeremo solamente il codice e le configurazioni necessarie ad utilizzare un STS già esistente.

Prerequisiti per lo sviluppo
Per cominciare a sviluppare, sono necessari alcuni prerequisiti. Per questi si può fare riferimento alla guida
disponibile all'indirizzo http://social.technet.microsoft.com/wiki/contents/articles/3487.aspx
I prerequisiti sono quattro:

      Visual Studio 2010 (ma è possibile implementare soluzioni con WIF anche in VS 2008)
      Microsoft IIS7 (con .NET WCF HTTP Activation installato)
      Microsoft Windows Identity Foundation (WIF) Runtime
      Microsoft Windows Identity Foundation SDK

Si comincia
Come prima cosa abbiamo bisogno di un servizio STS da sfruttare, pertanto utilizzeremo SelfSTS dell'ottimo

                                                                                                             pag. 1

Vittorio Bertocci reperibile al seguente link http://archive.msdn.microsoft.com/SelfSTS/
SelfSTS è un tool che consente di configurare ed eseguire in pochi semplici passaggi un STS minimale, ma
perfettamente funzionante a scopo di test. Vediamo come funziona. Appena eseguito, l'interfaccia si presenta
nel seguente modo:

Il tool ha già a disposizione un certificato digitale, ma in caso di necessità è possibile generarne velocemente
uno uno nuovo tramite il pulsante "Generate New…".
Nel campo Endpoint troveremo l'url presso il quale sarà reso disponibile il servizio STS ed un secondo indirizzo
"Metadata" che descrive il servizio stesso e che utilizzeremo per configurare la nostra applicazione.
Il pulsante "Edit Claim Types and Values" ci presenta una griglia dove andremo ad inserire i claim che vogliamo
ci vengano forniti nel token. Per il nostro test, i valori già presenti di default sono sufficienti.

                                                                                                           pag. 2

Premendo il pulsante "Start" sulla form principale di SelfSTS avremo un STS perfettamente funzionante.
A questo punto siamo pronti per scrivere la nostra applicazione di test. Eseguiamo quindi Visual Studio e se
siamo su Windows Vista o Windows 7, ricordiamoci di eseguirlo come utente amministratore. Creiamo un
progetto di tipo "ASP.NET Web Application" che chiameremo "WIFTest".

Nella pagina Default.aspx aggiungeremo nella form, il seguente markup:

Utente: 

e nel suo code behind metteremo il seguente codice:

protected void Page_Load(object sender, EventArgs e)
{
    Utente.Text = Context.User.Identity.Name;
}

A questo punto siamo pronti per configurare la nostra applicazione per l'utilizzo del STS. Ricordiamoci che
Visual Studio va lanciato da utente amministratore nel caso in cui si utilizzi Vista o Windows 7. Facciamo click
con il tasto destro sul nostro progetto web e selezioniamo la voce "Add STS reference…".

                                                                                                             pag. 3

Verrà mostrato un wizard che ci chiederà l'ubicazione del nostro web.config e l'url principale nostro sito.
Possiamo prendere quest'ultimo l'indirizzo eseguendo l'applicazione e copiando l'url dalla barra dell'indirizzo
del browser o verificando il numero di porta utilizzata dalla sezione Web presente nelle proprietà
dell'applicazione.

Poiché in uno scenario di produzione è "caldamente" consigliato di accedere al servizio STS tramite protocollo
https, il wizard ci darà un messaggio di warning al quale risponderemo "Yes" per proseguire. Poiché siamo in
fase di sviluppo possiamo permetterci di utilizzare una modalità meno sicura, ma che al momento risulta più
semplice da configurare.

Nella maschera successiva il wizard ci propone tre modalità:

      No STS
      Create a New STS project in the current solution
      Use an existing STS

                                                                                                            pag. 4

La prima delle opzioni provvederà ad una configurazione molto ridotta, mentre la seconda aggiunge alla nostra
solution un nuovo sito web con un'impementazione minimale di un STS. La terza prevede, invece, l'utilizzo di un
STS già esistente, pertanto selezioneremo questa ultima opzione ed inseriremo nella textbox associata,
l'indirizzo contenuto nel campo "Metadata" della form principale di SelfSTS.

Se abbiamo già avviato il servizio STS, premendo il pulsante "Test location…" otterremo un xml con i metadati
associati al servizio.
Premiamo il pulsante "Next" ed ignoriamo nuovamente il warning relativo al mancato utilizzo del protocollo
https. Nella pagina successiva selezioniamo "Disable certificate chain validation", poiché stiamo utilizzando un
certificato digitale di test, e premiamo "Next". Lo stesso facciamo per lo step successivo, scegliendo la voce "No
encryption". Vedremo in un prossimo articolo come generare i certificati digitali ed utilizzarli nei vari scenari per
ottenere la sicurezza necessaria.
Per finire premiamo nuovamente il pulsante "Next" e poi "Finish".

                                                                                                               pag. 5

Il wizard apporterà alcune modifiche al nostro progetto aggiungendo un file xml contenente i metadati
descrittivi per la nostra applicazione ed alcune modifiche al file web.config
In particolare, il wizard aggiunge nel web.config gli handler necessari alla gestione del processo di
reindirizzamento verso e dal STS.

Nel caso in cui la nostra applicazione web abbia come target di compilazione la versione 4.0 del framework
.Net, può capitare che il wizard non esegua correttamente tutta la configurazione necessaria a livello di web
config, pertanto dobbiamo assicurarci che nel web.config sia presente la seguente sezione:

                                                                                                           pag. 6

Inoltre, le impostazioni di sicurezza legate alla versione 4.0 fanno sì che la redirect fatta dal STS verso il nostro
sito, a valle dell'autenticazione, contenga nell'url alcuni tag ritenuti potenzialmente pericolosi. Per gestire
questa problematica si possono effettuare due tipi di interventi sull'applicazione. Il primo prevede una
regressione alla versione 2.0 del sistema di validazione delle richieste http tramite l'inserimento del seguente
elemento nella sezione system.web del nostro web.config:

È una soluzione semplice, tuttavia impatta sul meccanismo di validazione dell'intero sito, e ne diminuisce la
sicurezza. Il sistema migliore è quello di fornire un'implementazione custom che estenda il validatore di base. Il
codice, è il seguente:
public class WIFRequestValidator : RequestValidator
{
    protected override bool IsValidRequestString(HttpContext context, string value,
RequestValidationSource requestValidationSource, string collectionKey, out int
validationFailureIndex)
    {
        validationFailureIndex = 0;
        if (requestValidationSource == RequestValidationSource.Form &&
collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
        {
            SignInResponseMessage message =
WSFederationMessage.CreateFromFormPost(context.Request) as SignInResponseMessage;
            if (message != null)
            {
                return true;
            }
        }
        return base.IsValidRequestString(context, value, requestValidationSource,
collectionKey, out validationFailureIndex);
    }
}

 Per poter compilare, aggiungiamo un riferimento all'assembly Microsoft.IdentityModel. Infine, inseriamo il
riferimento alla classe del validatore nella sezione system.web del web.config:

Ora che tutto è configurato, eseguiamo l'applicazione. Potremo notare alcune operazioni di reindirizzamento
verso e dal STS. Infine il browser verrà indirizzato nuovamente verso la pagina di default della nostra
applicazione web, che mostrerà il nome dell'utente correntemente autenticato. In particolare, l'identificativo
dell'utenza che viene poi impostata come Name dell'Identity corrente all'interno del HttpContext corrente è
contenuto nella claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name che possiamo
visualizzare, e all'occorrenza cambiare, tramite il pulsante "Edit Claims Types and Values" presente sull'utility
SelfSTS.

                                                                                                                 pag. 7

È da notare che il nuovo meccanismo di autenticazione si integra perfettamente con ASP.Net. Questo vuol dire
che, se abbiamo utilizzato i meccanismi messi a disposizione da ASP.Net, il passaggio a questo tipo di
autenticazione è ,nella maggior parte dei casi, un'operazione trasparente. Non sono infatti necessarie modifiche
al codice esistente ed alle eventuali configurazioni di autorizzazione presenti nelle sezioni authorization dei
web.config della nostra applicazione web.

Conclusioni
Abbiamo visto come far sì che un'applicazione web deleghi ad un STS il compito di autenticare l'utente. Nel
prossimo articolo, vedremo come viene gestita anche la parte di autorizzazione e scenderemo un po' più nei
dettagli implementando un STS.

Riferimenti
[1] WIF Portal: http://msdn.microsoft.com/en-us/security/aa570351

[2] SelfSTS: http://archive.msdn.microsoft.com/SelfSTS/

                                                                                                          pag. 8