Windows Identity Foundation - Introduzione allo sviluppo

Scritto da  Luca Cestola il mercoledì 21 settembre 2011
Linguaggio:    •  Framework:    • 

Download sorgenti

Download pdf

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 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 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.

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: <asp:literal runat="server" ID="UserId" />

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…".

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

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".

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:

<httpModules>

  <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"  />

  <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"  />

  <add name="ClaimsAuthorizationModule" type="Microsoft.IdentityModel.Web.ClaimsAuthorizationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"  />

</httpModules>

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:

<httpRuntime  requestValidationMode="2.0"  />

È 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:

<httpRuntime  requestValidationType="WIFTest.WIFRequestValidator, WIFTest"  />

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.

È 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/