Sono un Trainer MCT e Consulente IT freelancer; particolarmente sensibile alle tematiche Mobile e Cloud, sono attivo nel mondo Community soprattutto su Windows Azure e Windows Phone. Mi è stato riconosciuto l’MVP per due anni consecutivi e sono pluricertificato su diversi vendor (MS, Sun, Apple, Cisco, IBM).
Come ultimo articolo prima della pausa estiva faremo un Lab abbastanza articolato e completo, in cui andremo a configurare un Endpoint su AppFabric Access Control V2, utilizzeremo e gestiremo i Claims e customizzeremo la parte di autenticazione dell’utente.
Possiamo partire dalla costruzione di una applicazione Web sulla base del template standard di Visual Studio 2010, rimuovendo:
Parte Azure
A questo punto ci rechiamo sul pannello di controllo di ACS, ovvero su http://windows.azure.com nella sezione “Service Bus, Access Control & Caching”. Chiaramente ci interessa l’ACS, quindi selezioneremo Access Control e poi “New namespace”
Un volta scelto il nome del namespace (globalmente univoco), la regione e la Connection Pack Size (di cui rimandiamo l’approfondimento alla parte licensing), avremo creato il nostro namespace AppFabric sia per ACS che per SB. Ora andiamo nel portale relativo alla gestione di ACS, cliccando su Access Control Service nella schermata precedente.
Ora non ci resta che aggiungere tutti gli Identity Providers che intendiamo supportare nella nostra applicazione. Consideriamo che essi dovranno essere WS-Federation compatibili per una piena integrazione trasparente; per esempio Yahoo! e Google lo sono e si possono aggiungere direttamente dal pannello:
Ora bisogna stabilire il trust con l’applicazione locale che abbiamo creato prima, andando a definire nella sezione “Relying party applications”, le seguenti impostazioni:
Come da screenshot abbiamo generato un nuovo gruppo di regole, presente ora nella sezione Rule Groups del pannello. Ora possiamo recarci lì, selezionare il gruppo appena creato che avrà un formato simile a “Default Rule Group for [AppName]”, e generare le regole di default per tutti i provider selezionati. Per finire, andiamo a prendere nota dei vari endpoint che ACS ha impostato per il servizio di federazione (sotto Application Integration):
Parte Client
Avendo “pulito” la soluzione da tutti i fronzoli di autenticazione, possiamo applicazione STS alla nostra soluzione, cliccando con il destro nel Solution Explorer e poi Add STS Reference. Si aprirà il wizard e dovremo inserire:
A questo punto possiamo far partire la soluzione e ci verrà chiesto di autenticarci con uno dei provider scelti prima in fase di setup della parte Azure.
Mapping dell’Input Claim su un Output Claim
Abbiamo detto precedentemente che ACS fa anche, in qualità di FP, la trasformazione dei claims in ingresso: per cui vediamo come fare. Questo esempio vuole creare l’infrastruttura capace di riconoscere un tale utente Windows Live ID come Administrator e quindi fare in modo che tale sia il ruolo “rilevato” dall’applicazione ASP.NET, con le classiche chiamate IsInRole, etc.
Intanto dovremmo fare in modo di capire, quando ci stiamo loggando con tale utente, quale sia il valore del Claim in ingresso all’applicazione. Per questo possiamo usare questo tool: http://archive.msdn.microsoft.com/TokenVisualizerCtrl che non fa nient’altro che visualizzare sulla pagina in cui lo inseriamo (è un server control) le informazioni sui Claims. Trovata una info di questo tipo:
Possiamo copiare il claim value negli appunti e tornare sul pannello online di configurazione di ACS. Ora torneremo sui Rule Groups e sul gruppo di regole precedentemente creato, per aggiungere una regola di trasformazione custom:
A questo punto abbiamo operato la trasformazione e quando l’utente X si loggerà tramite Live ID, il suo Input claim verrà trasformato in un output claim compatibile con WIF, il quale inietterà nella applicazione ASP.NET il necessario per far funzionare l’integrazione con il meccanismo di autorizzazione esistente.
Personalizzazione della pagina di Login
By Default, la pagina di login è hostata su ACS, ma possiamo invertire questo pattern per personalizzarla. Ci rechiamo al solito alla console di ACS e, nella sezione Application Integration, selezioniamo la nostra applicazione sotto la voce Login Pages. A questo punto possiamo scegliere di scaricare una pagina di Login di esempio (con gli opportuni link a ACS) e personalizzarne i CSS:
Per esempio così:
div.SignInContent { text-align: center; margin-left: auto; margin-right: auto; border: solid 1px #BBBBBB; position: relative; width: 1020px; height: 170px; } div.Banner { padding-top:10px; padding-bottom:10px; text-align: center; margin-left: auto; margin-right: auto; background: none repeat scroll 0 0 #4B6C9E; color: #F9F9F9; border-top: solid 1px #BBBBBB; border-left: solid 1px #BBBBBB; border-right: solid 1px #BBBBBB; width: 1020px; } div.LeftArea { padding:15px 15px; width: 960px; height: 100%; position: absolute; top: 0px; left: 0px; }
Ora abbiamo quasi finito, dobbiamo solo configurare il Web.config per fare in modo che si possa arrivare alla pagina di login liberamente:
E poi dire all’applicazione che il nuovo url di autenticazione è interno e in particolare:
Conclusioni
Abbiamo configurato ACS per una applicazione web, mappato i claims in ingresso e personalizzato la pagina di login, il tutto senza una riga di codice.