25

Jul

Windows Azure – Azure e applicazioni Claims-based

Si parte chiaramente dalla compresione del post precedente per mostrare come in Azure, ancora di più che nei sistemi tradizionali, l’approccio ad Claims può essere vincente (pur con qualche difficoltà). A parte la scomodità di gestire un account per applicazione e/o di gestirne puntualmente la complessità e l’infrastruttura di autenticazione, quando ci apprestiamo a muovere un applicazione sul Cloud spesso i nostri sistemi di autenticazione custom potrebbero non essere facilmente “trasportabili”.

Per cui siamo sempre più vicini al concetto di esternalizzare la gestione dell’Identità, preoccupandoci solo ed esclusivamente di erogare un servizio a chi possegga appunto, un documento valido. Tecnicamente parlando ciò che avviene, riprendendo il flusso del post precedente, è:

  • A richiede una risorsa X a B
  • B dice che è C ad occuparsi dell’autenticazione o perlomeno dice di tornare con un documento valido.
  • A si reca da C, viene autenticato e viene creato un file (XML, Json o altro), opportunamente firmato da C, da presentare a B
  • Chiaramente B si deve fidare di C e, al momento della presentazione del token, lascia passare l’utente A verso la risorsa X

D’ora in poi chiameremo C, l’STS (Security Token Service).

In .NET i servizi per gestire l’Identity sono sotto il cappello di Windows Identity Foundation. WIF è composto da tre parti:

  • FAM: è la parte che processa i token e che, ancora prima di riceverli, ri-dirige la richieste non autenticate al giusto STS. Ricevuto il token lo parsa e inietta in ASP.NET un IClaimsPrincipal.
  • SAM: è la parte che gestisce la sessione e i cookies relativi
  • CAM: è la parte che effettivamente gestisce l’autorizzazione ed è completamente integrata nel meccanismo a ruoli di ASP.NET

WIF in Windows Azure

Questo gioco funziona in uno scenario in cui il server sia uno, ma nel caso cloud? è vero che al client poco importa, ma il Load Balancer è imprevedibile e se ci fossero 10k di istanze sarebbe dura fare supposizioni in merito alle richieste.

Il processo di orchestrerebbe così:

  • Client chiede la risorsa all’URI su Azure
  • Una istanza risponde con una richiesta di autorizzazione verso STS
  • STS genera il token e il client torna da Azure andando su una specifica istanza X, scelta dal load balancer.
  • A quel punto SAM salva il cookie, che di default viene crittografato in DPAPI, rendendone impossibile il decrypt sulle altre istanze

L’unica soluzione è rendere sicuro il cookie in un altro sistema, per esempio utilizzando un certificato SSL già utilizzato dalla applicazione web.

by Roberto Freato on 7/25/2011
Post archive