28

Jul

Windows Azure – AppFabric Access Control Service

Abbiamo capito come si presenta lo scenario Claims-based e chi fa cosa nel processo generale di gestione dell’identità.

Ora però portiamo ad esempio un’ulteriore e voluta complicazione: se non fosse più uno solo il “tipo” di client da autenticare? Mettiamola meglio: se ci fossero diverse entità in gioco, con diversi sistemi di autenticazione, che si debbano avventurare verso la nostra applicazione? Allora non potremmo più dirigere tutte le richieste non autenticate ad un solo STS, ma dovremo gestirne più di uno.

In uno scenario più semplice, possiamo supporre che all’utente venga chiesto con che provider proseguire (del tipo: LiveID, Facebook, Google Account, etc) e utilizzare quindi diversi STS che però tornino alla stessa applicazione target. A questo punto si introduce un problema: il token generato dai vari STS sarà uguale? Al 90% no, come è giusto che sia, in uno scenario in cui ogni attore può fornire dati diversi e in diverso formato.

Ulteriore ed ultima domanda: come fa l’applicazione a gestire l’eterogeneità dei vari token? Deve prevedere un meccanismo di discernimento ad-hoc? E allora non stiamo ritornando ad una soluzione custom?

La risposta a tutto questo è l’aggiunta di un ulteriore layer di servizio che chiamiamo Federation Provider (FP in seguito). Un FP ha il compito di prendere in ingresso N tipi di token diversi e generare una trasformazione comune da inviare all’applicazione target. AppFabric Access Control Service è proprio un FP su cui possiamo specificare la logica di trasformazione e il trust per i nostri token e applicazioni. ACS risolve anche il problema della scelta dei provider di autenticazione, presentando all’utente un elenco dei provider supportati.

Il concetto teorico sottostante ad ACS è quindi molto semplice, ne vedremo un esempio nei prossimi lab.

by Roberto Freato on 7/28/2011
Post archive