Introduzione a Windows Identity Foundation: la Claims Identity
Scritto da
Luca Cestola
il
mercoledì 19 maggio 2010
Linguaggio:
•
Framework:
•
Livello: 200
Windows Identity Foundation è una nuova
componente del framework .NET che permette di
spostare all'esterno delle applicazioni la logica legata
all'identità degli accessi. Questo permette di creare
applicazioni più sicure, tramite l'uso di un modello semplificato
basato su claims (attestazioni). La nuova componente si integra con
Windows Communication Foundation offrendo quindi
un nuovo strumento per la gestione della sicurezza nelle
comunicazioni, di cui possono beneficiare ampiamente applicazioni e
servizi. In questo primo articolo scopriamo quali sono i concetti
alla base di questo nuovo strumento.
Autenticazione e autorizzazione
Quando si accede ad un'applicazione è prassi piuttosto comune
che il riconoscimento dell'utente avvenga attraverso un
identificativo ed una password. In altri casi potrebbero essere
richiesti codici generati da token hardware o dati biometrici. Ad
ogni modo chiunque tra sviluppatori, analisti ed esperti di
architetture si è prima o poi dovuto confrontare con la gestione
degli accessi e con le conseguenze che questa ha nello sviluppo di
un software, soprattutto quando ci si muove sul terreno
sducciolevole delle applicazioni distribuite. In termini di
sicurezza, due concetti fondamentali sono
l'autenticazione e
l'autorizzazione. La prima riguarda il
riconoscimento di chi (persona o software) deve accedere ad un
sistema informatico, mentre la seconda riguarda le risorse o le
funzionalità a cui è possibile accedere.
Da un punto di vista tecnologico, le soluzioni per gestire le
fasi di autenticazione ed autorizzazione sono numerose e
indirizzano requisiti diversi. Si va dalla gestione locale degli
accessi a complete soluzioni Identity Access
Management. Il framework .NET integra i concetti di
autenticazione e autorizzazione a diversi livelli e ne offre una
visione agnostica rispetto alle specifiche implementazioni. È per
questo che in ASP.NET, ad esempio, è possibile rendere disponibile
una risorsa ai soli utenti autenticati prescindendo dal meccanismo
di autenticazione scelto che può essere indifferentemente la
sicurezza integrata di Windows o l'inserimento di credenziali su
una pagina web. Anche per l'autorizzazione il concetto è slegato
dalla specifica implementazione ed è possibile proteggere porzioni
di codice, servizi o pagine web dichiarando le utenze o ruoli che
possono accedervi. La protezione delle risorse ed il meccanismo di
sicurezza utilizzato sono quindi nettamente separati ed è possibile
scegliere la soluzione da applicare a seconda delle necessità,
senza che questo comporti cambiamenti rilevanti.
Tra le diverse soluzioni disponibili ce n'è una che riceve
sempre più attenzioni da parte di un numero crescente di settori.
Si tratta dell'autenticazione ed autorizzazione basata su
claim, termine che possiamo tradurre come
"attestazione". Il concetto non è nuovo, anzi a dire il vero sono
già diversi anni che se ne discute, ma se ne sente sempre più la
necessità, poiché offre un approccio che permette di spostare il
problema dell'autenticazione e dell'autorizzazione al di fuori del
dominio applicativo offrendo una soluzione relativamente semplice
anche in scenari molto complessi.
Cominciamo con l'esame di uno degli elementi fondamentali del
modello: la claim.
Claim
Una claim è una struttura dati che contiene poco più
che una semplice informazione. Tale informazione può riferirsi ad
esempio ad un nome, un indirizzo email oppure può esprimere una
caratteristica come l'età o la cittadinanza. Può anche
rappresentare, ad esempio, il diritto a poter compiere un
determinato tipo di operazione o l'appartenenza ad uno o più ruoli
(visualizzatori, utenti, amministratori, ecc...). In teoria non ci
sono vincoli al tipo di informazione che può essere rappresentato
dalle claim, anche se risulta fondamentale che le informazioni in
esse contenute possano essere comprese ed univocamente interpretate
da chi le riceve. Per questo motivo una claim deve essere
rappresentata con un formato condiviso che ne permetta la
comprensione. Il formato a cui si fa riferimento è il
Security Assertion Markup Language (SAML) che attualmente è alla sua
versione 2.0 ed è uno standard OASIS, un
consorzio che promuove l'adozione di standard aperti, di cui fanno
parte società di grosso calibro tra cui Microsoft, IBM e
Oracle.
La struttura di una claim è relativamente semplice. Gli elementi
che la compongono sono i seguenti:
Il type identifica il tipo di informazione che si vuole
rappresentare, mentre il value ne esprime il relativo valore. Un
type è normalmente rappresentato da un Uri che identifica il tipo
di informazione in modo univoco. Il type che esprime, ad esempio,
un indirizzo email è rappresentato dal seguente uri:
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Il right specifica invece se la claim rappresenta un'identità o
una caretteristica che si possiede ed è descritto tramite le
seguenti uri:
-
http://schemas.xmlsoap.org/ws/2005/05/identity/right/Identity;
-
http://schemas.xmlsoap.org/ws/2005/05/identity/right/PossessProperty.
Una claim, come dicevamo, può contenere qualsiasi tipo di
informazione, pertanto potremmo decidere in autonomia l'uri che ne
identifica il type. In questo caso le diverse tipologie di claim
devono essere condivise tra chi emette e chi riceve la claim. Per
questo motivo lo standard SAML 2.0 fornisce di base un ampio set di
tipologie predefinite con lo scopo di standardizzare alcuni tipi di
informazioni più comuni. Disporre di tipi condivisi e univocamente
definiti da uno standard, permette la comprensione delle
informazioni veicolate dalle claim tra sistemi di organizzazioni
diverse, senza necessità di doversi intendere a priori sul loro
significato.
Entità del modello claim-based
L'attendibilità delle informazioni contenuta nelle claim è
legata al concetto di Trust, ovvero la relazione di
fiducia che si ha con la fonte di informazione. Il
concetto di trust è un elemento fondamentale per un modello
claim-based. Senza di esso il modello non avrebbe alcun valore
pratico poiché non saremmo in grado di verificare
l'attendibilità delle informazioni. Vediamo quindi
quali sono le entità coinvolte in uno scenario claim-based e come
interagiscono tra di loro per garantire la sicurezza negli
accessi.
Col termine Relying Party (RP)
si identifica un servizio o un'applicazione web che delega almeno
la fase di autenticazione ad una entità esterna che è chiamata
Issuing Authority (IA), che
rappresenta l'ente di cui ci fidiamo. Il RP espone pubblicamente le
policy necessarie all'accesso, ovvero l'insieme delle claim
opzionali o obbligatorie che un client deve presentare per ottenere
l'accesso. In tal modo quando la Issuing Authority riceve una
richiesta di accesso ad un determinato RP riceve contestualmente
l'insieme delle claim di cui il client necessita. La IA
richiederà al client le credenziali di cui ha bisogno per
autenticare il richiedente e se l'esito è positivo potrà fornire al
client le claim richieste comprensive dei relativi valori.
Contestualmente dovrà fornire una prova che l'autenticazione
ha avuto successo. Questo compito spetta ad una componente chiamata
Secure Token Service (STS). Un STS è un software
in grado di creare un Security Token ovvero un insieme di claim
digitalmente firmate con il certificato della IA. Tramite la firma
apposta dalla componente STS, il RP è in grado di verificare che un
insieme di claim siano attendibili in quanto certificati
dalla IA che si considera attendibile.
Un STS può essere esposto, ad esempio, come web
service ed in questo caso è direttamente raggiungibile da
uno smart client che necessiti di un Secure Token da fornire al
servizio al quale voglia accedere. In questo caso il client svolge
un ruolo cosiddetto attivo e deve essere in grado
di effettuare una chiamata al web service dell'STS. Il client
richiede al RP le policy di accesso esposte su uno specifico
endpoint e le rigira al STS al quale fornirà anche le credenziali
di accesso. L'STS verificherà le credenziali ed emetterà un
Security Token che invierà al client. Il client fornirà a sua volta
il Security Token al RP ottenendo così l'accesso ai suoi
servizi.
Per capire meglio il processo, riportiamo i diversi passaggi nel
grafico in Figura 1.
Figura
1 : Scenario
di base con l'utilizzo di smart client
Non sempre un client è in grado di gestire in autonomia il
processo di autenticazione presso un STS. È il caso delle
applicazioni web, dove il client è un web browser. In questo
scenario, detto passivo, l'autenticazione viene eseguita
dalla IA tramite una web application. Il flusso in questo caso
è leggermente diverso e prevede l'utilizzo dei meccanismi http per
il trasporto delle informazioni. L'utente che vuole accede,
indirizzerà il browser all'applicazione web del RP. Se non si è già
autenticati, l'applicazione reindirizzerà il browser verso una
pagina di accesso esposta dalla Issuing Authority fornendo al
contempo le policy di accesso. Tramite la pagina di accesso vengono
verificate le credenziali e se l'esito è positivo, verrà effettuata
una richiesta interna al dominio della IA verso l'STS per
l'emissione del Secure Token da restituire al client. Il processo è
schematizzato in Figura 2.
Figura
2 : Scenario
di base con l'utilizzo di un web browser
Considerazioni finali
L'impiego del modello claim-based permette di spostare
all'esterno le problematiche relative
all'autenticazione ed autorizzazione degli accessi. I benefici che
si traggono da questo approccio sono molti. Uno dei più ovvi è
quello di poter facilmente disporre di un meccanismo di
Single Sign On per le nostre applicazioni, ma è
solo un aspetto di un quadro ben più complesso. La validità, anche
temporale, di un secure token è verificabile in piena autonomia da
chi lo riceve senza dover interagire con altri sistemi. Questo vuol
dire che le informazioni contenute nel token possono essere
propagate su un'intera catena di componenti e sistemi che saranno
in grado di considerarle attendibili. Se si pensa ad architetture
N-Tier o SOA si capisce meglio il valore di questo approccio che
elimina una vasta serie di problematiche. Inoltre, in scenari di
sicurezza federata (Federated Security) l'utilizzo del modello
claim-based consente l'accesso e la collaborazione tra differenti
sistemi informatici anche tra organizzazioni diverse. In questi
scenari una tra le caratteristiche fondamentali è la capacità di
instaurare una relazione di fiducia con STS esterni. Questo
permette ad utenti appartenenti ad organizzazioni diverse l'accesso
regolato ai relativi sistemi, senza che si renda necessario il
provisioning delle specifiche utenze nei diversi domini.
Nel prossimo articolo cominceremo ad analizzare le
caratteristiche specifiche di Windows Identity Foundation e vedremo
come utilizzarle per applicare il modello claim-based alle nostre
applicazioni.
Tags: WIF