Introduzione ad Active Directory Federation Services

Ciao a tutti, con il prossimo articolo vogliamo approfondire un concetto che esiste da molto tempo ma che oggi a maggior ragione rientra a passo deciso nel mondo del Cloud e dei servizi. Per la stesura ringraziamo Marco Sanfilippo, di cui riporto una breve descrizione:

”Sono uno studente di Ingegneria gestionale all'università di Udine e Microsoft Student Partner dal 2010. Ormai da diversi anni mi interesso principalmente di sistemi informatici e reti per le aziende. Ho collaborato nella realizzazione di piccole infrastrutture basate su Active Directory e ad alcuni progetti per web-application che si appoggiano ad AD FS per l'autenticazione degli utenti. All'università collaboro anche con un'associazione studentesca che si occupa di informatica e open source.”

Il termine cloud computing, o più semplicemente cloud, è ormai entrato nel novero delle parole utilizzate quotidianamente da tutti coloro i quali, per un motivo o per un altro, operano nel campo dell'IT.

Sempre più aziende decidono di spostare parte dei servizi, una volta implementati on premises, sulla cloud, sia per la possibilità di variare le risorse a seconda delle esigenze, sia per la minore necessità di manutenzione richiesta qualora non si debba gestire la piattaforma su cui i servizi vengono eseguiti.

Ovviamente un'azienda con un numero di dipendenti sufficientemente elevato vorrà sempre mantenere un certo numero di server all'interno dei propri datacenter per fornire anche nella peggiore delle ipotesi almeno dei servizi base ai propri utenti, come i servizi di rete, Active Directory, ecc.

Esistono anche problematiche burocratiche che impediscono di rivolgersi a soluzioni esterne per certi servizi, come ad esempio problemi relativi alle normative sulla privacy qualora le credenziali di un utente (username e password) vengano archiviate su banche dati esterne.
Un caso tipico potrebbe essere quello di un'università che decida di avvalersi di un servizio di webmail per sostituire un servizio interno: sarebbe inconcepibile pensare di fare firmare un documento aggiuntivo ad ogni singolo studente per autorizzare l'archiviazione delle credenziali presso terzi.

Anche se gli scenari d'uso per i quali sono stati pensati sono antecedenti all'era "cloud", i servizi federativi di Active Directory (AD FS), introdotti con Windows Server 2003 R2, diventano uno strumento estremamente potente per consentire ad applicazioni e servizi web remoti di dialogare con i servizi AD interni ad un’organizzazione senza che questi debbano essere esposti all'esterno e riducendo quindi le problematiche inerenti la sicurezza.

Il concetto di servizio federativo è basato sul presupposto di "fiducia" tra due o più organizzazioni distinte ma con la necessità di accedere a dati o risorse dell'una o dell'altra da parte dei rispettivi utenti.
L'idea di base è per certi versi simile a quella del meccanismo dei certificati SSL, in cui un ente di certificazione esterno all'organizzazione, ma comunque affidabile, certifica l'identità di un sistema o servizio.

Il metodo con cui si verifica un'identità senza avere un collegamento diretto con i sistemi di autenticazione è basato sui concetti di claim e token.
L'esempio classico nella vita reale è quello del ragazzo (l'utente) che decide di andare al cinema per vedere un film VM14 (il servizio o la risorsa). Alla biglietteria del cinema non possono ovviamente mantenere una banca dati completa della popolazione quindi, per verificare l'identità senza doversi collegare direttamente ad un database della pubblica amministrazione, si affidano ad un documento d'identità (un token) rilasciato da un'organizzazione conosciuta, che riporta tra i vari dati (i claim) anche la data di nascita.

Nel caso di AD FS, si parte dagli attributi di un oggetto AD che vengono incapsulati in un token, il cui servizio emittente è universalmente noto come Security Token Service (STS). Il token, contenente dei metadati descritti mediante il linguaggio SAML (Security Assertion Markup Language), viene poi in genere firmato direttamente dal STS mediante un certificato per evitare che i dati contenuti al suo interno possano essere alterati rendendo quindi Il token a tutti gli effetti un documento d'identità, rilasciato per un certo periodo di tempo ad un'applicazione o un servizio per un determinato utente. Il token può anche essere cifrato nel caso viaggi su canali non sicuri.

Tornando all'esempio preso in esame all'inizio dell'articolo, supponendo che il sistema informatico dell'università sia basato su Active Directory, AD FS si occuperebbe di generare i token per gli utenti che desiderino effettuare il login sulla webmail, identificandoli come studenti, docenti, personale amministrativo, ecc.
Non sussisterebbero più quindi problematiche relative all’archiviazione delle credenziali, che rimarrebbero all’interno di server di proprietà dell’università e non verrebbero trasmesse a terzi.

A partire da Windows Server 2008 è possibile utilizzare la versione 2 di AD FS mediante un download esterno [1] in quanto aggiungendo il ruolo AD FS dal Server Manager viene installata la versione 1, mentre su Windows Server 2012 l'aggiunta del ruolo comporta l'installazione della versione 2, sebbene sia sempre possibile installare anche la versione 1 per compatibilità con applicazioni web non aggiornate.

Il setup di AD FS si occupa di configurare un servizio web ASP.NET che gira su IIS all'interno di un server membro di un dominio (qualora non si stia installando un proxy, come si vedrà in seguito) . Durante l’installazione, se non è già presente, viene automaticamente installato il ruolo di server IIS con il supporto per le applicazioni ASP.NET.

La gestione del servizio si effettua ovviamente mediante uno snap-in MMC oppure via PowerShell come qualunque altro servizio.

Esattamente come accade per i Domain Controller, è bene avere almeno due sistemi per load balancing e failover.
Nel caso di requisiti di high availability in cui il numero di server inizi ad aumentare, è possibile decidere di spostare la configurazione di AD FS su SQL Server, operazione che può essere eseguita mediante PowerShell [2].
In fase di installazione AD FS richiede quindi se si vuole installare un server singolo, se si vuole creare il primo server di una configurazione server farm, oppure se il server corrente andrà aggiunto ad una server farm esistente.

Per questioni di valutazione o sviluppo oppure per ambienti estremamente piccoli, è possibile utilizzare una configurazione stand-alone.

AD FS supporta inoltre la funzione di proxy, mediante la quale si mantengono isolati dall’esterno i server membri del domino. È quindi possibile configurare uno o più server come AD FS proxy, con l'enorme vantaggio che i proxy sono trasparenti per le applicazioni o per i servizi che si appoggiano ad AD FS.
L’uso dei proxy è subordinato ad una semplice configurazione dei server DNS, che risolveranno l’hostname del server in maniera differente a seconda che la richiesta arrivi dall’interno del dominio oppure dall’esterno.
L’autenticazione per gli utenti dall’interno del dominio può essere totalmente trasparente e automatica, mentre gli utenti che accedono dall’esterno, anche dal computer di casa oppure da un tablet mediante i proxy, dovranno inserire le credenziali in un web form.
AD FS non richiede inoltre particolari risorse e non è infrequente che tutta l’infrastruttura AD FS, ovvero server membri e proxy, sia virtualizzata.
Per scopi di test è possibile configurare un server con entrambi i ruoli AD DS e AD FS (ed eventualmente DNS) mentre è sempre caldamente raccomandato eseguire l’applicazione che vi si collegherà su un server differente.

Particolare importanza riveste la gestione dei certificati SSL del server AD FS e dei proxy.
Essendo i proxy, presumibilmente, esposti su internet per consentire l’autenticazione degli utenti ovunque si trovino, devono avere un certificato SSL rilasciato da CA attendibili per garantire agli utenti che si stiano autenticando effettivamente su un certo server e che le credenziali inviate siano cifrare.
I token, come già detto in precedenza, sono firmati per mezzo di un certificato, autofirmato, generato dal wizard durante la configurazione del primo server AD FS. Tale certificato può essere sostituito con uno firmato da una CA attendibile in maniera tale che qualunque applicazione vi si debba collegare non abbia problemi durante la validazione della catena, oppure deve essere importato nel sistema dove risiede l’applicazione che altrimenti in fase di verifica genererà un errore non potendo verificare la validità del certificato.
Qualora poi la comunicazione tra il server AD FS e l’applicazione che vi si aggancia non possa essere considerata affidabile, ad esempio perché l’applicazione non dispone di un certificato SSL valido, si utilizza un altro certificato per la cifratura del token.

Per permettere ad un’applicazione di accedere ad AD FS è necessario prima registrarla come Relying Party (RP). Nell’esempio del cinema all’inizio dell’articolo, la biglietteria del cinema sarebbe il RP, ovvero il servizio che valida l’identità dell’utente ed eroga il servizio a cui deve accedere. La registrazione del RP sul STS è una caratteristica di ADFS e di alcuni altri sistemi di autenticazione basati su claim e token per verificare l’identità del RP.

È possibile effettuare la registrazione automaticamente per mezzo di un wizard qualora l’applicazione disponga di un certificato valido per il server ADFS, oppure manualmente importando i metadati dell’applicazione, creati in fase di collegamento al server ADFS.
Le possibilità di modifica dei dati inviati da ADFS sono molte e parecchio articolate, inclusa la possibilità di appoggiarsi ad un database utenti (che in questo ambito è chiamato Identity Store) che non sia AD ma un database SQL o un servizio LDAP, oppure rinominare eventuali attributi prima di inviarli al RP, ad esempio perché l’applicazione è stata progettata per utilizzare e richiedere al STS uno username, mentre, magari per motivi di univocità, l’opzione migliore è che identifichi l’utente dall’indirizzo e-mail. In questo caso è possibile stabilire una regola custom che traduca l’indirizzo in username (partendo dal presupposto che l’applicazione non si faccia problemi a gestire caratteri come ‘@’ all’interno dell’username ovviamente).

Un’altra possibilità offerta è la sincronizzazione automatica dei metadati tra server ADFS e RP, nel caso quest’ultimo abbia bisogno di accedere ad altri attributi AD durante l’implementazione di nuove funzionalità.

Infine, per gli sviluppatori ASP.NET, ADFS rappresenta un’ottima alternativa per quanto concerne la gestione dell’autenticazione degli utenti in ambito business/enterprise. Infatti, sebbene sia possibile collegare un’applicazione web ad un STS come AD FS con Windows Communication Foundation (WCF) o altre librerie che svolgono funzioni simili, con l’introduzione di Windows Identity Foundation (WIF) a partire da .Net Framework 3.5 vengono messi a disposizione direttamente oggetti di alto livello che rappresentano identità e claim mentre WIF si occupa della lettura dei token, della verifica dei certificati e di altri particolari di cui lo sviluppatore o il team di sviluppo non deve più preoccuparsi, consentendo così anche ad applicazioni in origine concepite per utilizzare altri meccanismi di autenticazioni di agganciarsi a dei STS senza pesanti aggiunte o modifiche al codice, ma semplicemente, volendo, con un semplice wizard integrato in Visual Studio.

Con un utilizzo sempre maggiore di servizi cloud da parte di aziende di ogni dimensione, le possibilità di utilizzo sono in costante aumento, ad esempio AD FS è il sistema standard con cui si effettua la delega dell’autenticazione di servizi come Office365 o SharePoint. Considerando che la comunicazione avviene attraverso protocolli standard e che è possibile avere server AD FS su macchine virtuali nella cloud gli scenari d’uso di questo servizio diventano sostanzialmente illimitati.

[1] http://www.microsoft.com/en-us/download/details.aspx?id=10909
[2] http://social.technet.microsoft.com/wiki/contents/articles/948.ad-fs-2-0-migrate-your-ad-fs-configuration-database-to-sql-server.aspx