Inside Microsoft.comCome utilizzare Active Directory Federation Services

Jim Guthrie

Qui alla Microsoft forniamo una Extranet per dare ai nostri partner commerciali l’accesso a importanti risorse interne. L'architettura della Extranet richiede che ogni partecipante esterno all'organizzazione abbia un unico account di dominio per questo spazio. Questo account viene creato e gestito dai dipendenti di Microsoft e non dai

partner, per ovvie ragioni. Tuttavia, durante il funzionamento, l'esperienza per l'utente può essere meno soddisfacente e la responsabilità di Microsoft di gestire tali partner richiede talvolta molte risorse.

Ecco come funziona la Extranet. Quando un cliente o un partner accede a un'applicazione, gli viene chiesto di inserire le proprie credenziali. Durante la stessa sessione, se tale utente decide di accedere a una risorsa diversa gli verranno ancora richieste le credenziali. Queste richieste continueranno ogni volta che l'utente passerà da una richiesta all’altra. Se l'utente si è autenticato in un'applicazione che utilizza risorse multiple, come un database finanziario, deve autenticarsi per ogni risorsa in modo indipendente. Questa esperienza può essere fastidiosa per gli utenti.

Fortunatamente, utilizzando Active Directory® Federation Services (ADFS), possiamo risolvere facilmente il problema delle autenticazioni multiple. ADFS è un componente di Windows Server® 2003 R2 che semplifica il trust tra due o più organizzazioni consentendo di condividere più risorse mantenendo nel contempo la capacità per ciascuna organizzazione di gestire i propri utenti. In quest'articolo, illustrerò come Microsoft progetta di utilizzare ADFS per risolvere tale problema, fornendo le informazioni necessarie per implementare una soluzione simile. Prima di entrare nei dettagli, tuttavia, occorre dare un'occhiata alla Figura 1 per familiarizzarsi con la terminologia fondamentale di ADFS.

Figure 1 Terminologia ADFS

Una soluzione ADFS

Quando un utente tenta di accedere a un'applicazione in grado di riconoscere ADFS, il browser viene inviato alla Federation Service Resource (FS-R) per l’individuazione dell'area di autenticazione principale. Qui l'utente sceglierà quale set di credenziali utilizzare durante la sessione. A seconda dell’area di autenticazione principale scelta dal client, l'utente verrà reindirizzato al server di Federation Service Accounts (FS-A). È a questo server che riceverà un token di account valido (in un cookie) basato sulle credenziali nel modulo di Windows Live™ ID (noto in precedenza come Passport account), Windows Integrated Authentication o autenticazione SSL (vedere la Figura 2). In questo modello, è compito delle organizzazioni effettuare la manutenzione del proprio server di federazione degli account. Nel caso dei server partner di Microsoft, questa operazione elimina la responsabilità di Microsoft.com di gestire tutti gli account nell'ambiente. Naturalmente, se si implementa quel livello di responsabilità, è necessario scegliere attentamente le organizzazioni con cui ci si è federati ed è necessario assicurarsi che tali organizzazioni gestiscano attivamente le proprie informazioni di account.

Figura 2** Flusso ADFS **(Fare clic sull'immagine per ingrandirla)

La fase successiva consiste nel ritornare al server di FS-R per scambiare il token di account con un token di risorsa. Nella nostra configurazione, questo token contiene un elenco completo delle autorizzazioni concesse all’utente attraverso un processo di mapping delle attestazioni effettuato su FS-R. Ricevuto il token, l’utente ottiene la funzionalità Single Sign-On (SSO) sulle applicazioni in grado di riconoscere ADFS finché la sessione è aperta o fino a 24 ore per impostazione predefinita (questa finestra è configurabile). In tal modo si ottiene l’abilitazione SSO a queste applicazioni in grado di riconoscere ADFS, con un'esperienza utente più protetta ed efficiente. Per uno scenario completo del processo di autenticazione di ADFS, vedere l'articolo di Matt Steele dell’edizione di luglio 2006 di TechNet Magazine intitolato "Semplificare il Single Sign-On con ADFS".

Per mantenere la protezione delle risorse aziendali di Microsoft, abbiamo isolato il lato che accede a Internet dell'Extranet aziendale e di conseguenza ogni server dispone potenzialmente di due configurazioni. Consentiamo un trust unidirezionale da parte degli utenti aziendali interni e utilizziamo i server per fornire la protezione necessaria. Abbiamo anche un dominio separato per lo spazio Extranet nel quale forniamo agli utenti esterni l’accesso alle risorse necessarie.

Due aspetti principali che suscitavano molto interesse durante l'implementazione erano il bilanciamento del carico e le modifiche di file dei criteri ADFS. Il bilanciamento del carico era una sfida sia a livello globale che a livello locale. In fase iniziale, in produzione utilizzeremo il bilanciamento del carico globale dai nostri partner di Content Delivery Network (CDN) Akamai o Savvis per i cluster di server Web front-end in due regioni. Questa operazione assicurerà la disponibilità del sistema per gli utenti finali anche nell'eventualità, improbabile, che un paio di server regionali non siano in linea. Ciò viene realizzato mediante failover automatico basato sui servizi di controllo integrità del server forniti dai CDN. Inoltre, possiamo aggiungere facilmente altri cluster in futuro. Per realizzare un risparmio dei costi, le nostre distribuzioni di preproduzione hanno deciso di non utilizzare il servizio CDN.

A livello regionale abbiamo accoppiato i server per il failover locale mediante il clustering del bilanciamento del carico di rete (Network Load Balancing, NLB). Anche se non utilizziamo funzionalità speciali di bilanciamento del carico, come si potrebbe facilmente fare con l’hardware, utilizziamo NLB per ottenere una riduzione dei costi. Questa configurazione fornirà la stabilità per assicurare oltre il 99,9 percento di tempo di operatività in tutti gli ambienti supportati.

Un'altra sfida che abbiamo affrontato consisteva nell’assicurare che il file dei criteri ADFS, il backbone di ADFS, fosse correttamente distribuito ovunque nel nostro ambiente e che fossero replicate anche le modifiche al file. A questo scopo, sfruttiamo un'altra funzionalità incorporata di Windows Server 2003 R2, la Replica DFS (DFSR), un nuovo motore di replica multimaster basata sullo stato. Su ciascuno dei server back-end abbiamo attivato un'appartenenza al gruppo DFS-R con una replica full mesh di 24 ore. Ora, indipendentemente da dove avviene la modifica al file dei criteri, questo sarà distribuito a tutti i server. Finché controlliamo chi può modificare il file, abbiamo un servizio estremamente stabile e disponibile.

Nonostante abbiamo tentato di assicurare che tutte le modifiche siano effettuate attraverso lo snap-in ADFS, in pratica, abbiamo constatato che a volte è necessario aggiornare manualmente questo file. Durante l’aggiornamento manuale è importante ricordare che ADFS rileva la versione di questo file. Quindi è necessario incrementare il file in modo che le modifiche vengano applicate nell'ambiente:

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

È necessario inoltre ricordare che, come tutto XML, il file XML dei criteri rileva la distinzione tra maiuscole e minuscole. In tutto il file XML dei criteri esistono molti riferimenti alle applicazioni o ad altri server ADFS e in tutti i casi essi devono essere copiati verbatim da un server all’altro. Si notino gli esempi seguenti dove il primo, RevocationCheckFlags, è stato inserito manualmente e il secondo è un URL di applicazione attendibile modificato dall'interfaccia utente:

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

Per un livello di protezione aggiuntivo utilizziamo un altro componente di ADFS, Federation Service Proxy (FS-P), che assicura che i FS-R non possano accedere direttamente dalle richieste Internet in entrata. Abbiamo implementato i proxy in Microsoft.com attraverso l'uso di un singolo set di proxy per ospitare diversi ambienti ADFS nella nostra area di preproduzione. Durante l’organizzazione iniziale della tecnologia abbiamo scoperto che era necessario apportare una semplice modifica alla chiave del Registro di sistema per realizzare questa operazione. La chiave si trova in HKLM\Software\Microsoft\WebSSO. Modificando semplicemente il valore della directory iniziale in questa chiave è possibile utilizzare il proxy per diversi ambienti. Il valore predefinito era:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

Per passare da un ambiente all'altro la chiave deve essere modificata nel modo seguente:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

La creazione di un file batch può semplificare la gestione di questo processo. Sfortunatamente la versione attuale dello snap-in di MMC per ADFS non supporta il passaggio da un ambiente all'altro poiché esiste un rapporto uno a uno tra il proxy e il server di risorsa o di account. Questo è l'unico modo per ottimizzare l'utilizzo dei server proxy. Il risultato finale è una notevole riduzione dei costi poiché viene limitato il numero dei server fisici indipendentemente da quanti ambienti si sceglie di ospitare.

Da un punto di vista dell'architettura eseguiamo il nostro ambiente di preproduzione con computer virtuali, il che contribuisce alla riduzione dei costi. In tal modo si elimina la necessità di acquistare e dover sistemare sei server aggiuntivi. Fino ad oggi non abbiamo avuto problemi di prestazioni. Tuttavia, per rispondere alla richiesta notevolmente aumentata nell'ambiente di produzione, abbiamo deciso di utilizzare computer fisici con prestazioni superiori.

Non solo per Active Directory

Non solo Microsoft.com utilizza gli account di Active Directory per l'autenticazione, ma abbiamo anche integrato con successo gli account ID di Windows Live. Abbiamo scoperto che, grazie a Windows Live ID (WLID) 4.5, possiamo utilizzare un account di Windows Live ID di un singolo utente per delegare l’accesso alle risorse di Microsoft utilizzando una trasformazione di attestazioni personalizzata. Ciò rappresenta una notevole vittoria per il raggiungimento dell'autenticazione SSO poiché non richiediamo più un account di dominio specifico.

Le sfide che rimangono da affrontare

La maggiore sfida che stiamo affrontando è la gestione di ADFS per condividere i certificati per la firma di token. Utilizziamo certificati standard che rimangono validi solitamente per un anno prima di richiedere il rinnovo. Al momento del rinnovo ogni server avrà bisogno di essere conseguentemente aggiornato, il che avrà un impatto significativo sugli FS-R. Mentre ora è possibile trattare con 15 o 20 federazioni, vorremmo arrivare a gestirne almeno centinaia se non migliaia. Questo richiederebbe l'impiego di personale a tempo pieno per la gestione dei certificati SSL per ogni singolo ambiente. Abbiamo diversi team che stanno cercando i metodi migliori per automatizzare questa soluzione, ma non hanno deciso quale linea di condotta seguire.

Un’altra sfida da affrontare è il fatto che non tutte le applicazioni sono in grado di riconoscere ADFS. Per far sì che i siti sfruttino l'opportunità di ADFS, sono necessarie altre operazioni di programmazione. Lavoriamo a stretto contatto con il team di Microsoft® Office SharePoint® Services per assicurarci che la prossima generazione di SharePoint sia in grado di supportare le nostre esigenze di implementazione per ADFS.

Conclusioni

Esistono numerosi fattori da considerare quando si decide di passare a un modello ADFS. Uno di questi è il numero dei clienti di risorse che vi accederà. Il processo di impostare un trust tra le organizzazioni può essere un compito banale, ma scrivere, riesaminare ed eseguire criteri di accesso accettabili richiede tempo e impegno. Quindi, se si ha una sola risorsa alla quale i propri clienti accederanno, si dovrà decidere se ne vale la pena. Poiché il numero di risorse cresce, i benefici aumentano.

Per ulteriori informazioni, vedere Panoramica di ADFS e Active Directory Federation Services: verso un'identità federata e la gestione degli accessi.

Jim Guthriecollabora con Microsoft nel team operativo di Microsoft.com e, oltre a lavorare con ADFS, è un ingegnere di sistemi nel team di supporto per le piattaforme dei portali aziendali.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.