Active Directory Federation Services in Windows Server 2008 (parte1)
Che cos’è un Federation Trust?
Un Federation Trust è una relazione tra due organizzazioni all’interno di Active Directory Federation Services. Questo rapporto consente agli account autenticarsi in un organizzazione ed essere allo stesso tempo utilizzati per accedere alle risorse di un’altra organizzazione. Questa relazione di fiducia rende efficienti e sicure le transazioni online tra le organizzazioni-partner. Per stabilire un trust federativo, deve essere stretta una relazione tra i vari partner dell’organizzazione (partner account e partner risorse).
Account Partner. Questo partner organizzativo ospita e gestisce gli account utente utilizzati nel rapporto di fiducia. Gli account utente sono memorizzati in Active Directory o AD LDS.
Resource Partner. Questo partner organizzativo nel rapporto di fiducia ospita una o più applicazioni web-based. Questo partner di risorsa dà fiducia al partner account per autenticare gli utenti. Pertanto, quando si necessita di autorizzazioni per un’applicazione web, il partner di risorsa accetta token di protezione inoltrati dal partner account.
Componenti di AD Federation Services
Account Federation Server: Gli Account Federation Server si trovano nell’ organizzazione del partner account. Questi server sono utilizzati per autenticare gli account utente memorizzati in un archivio di Active Directory o un archivio di AD LDS. Gli Account Federation Server rilasciano i token di sicurezza che gli account utente possono utilizzare per accedere ai server federativi ospitati dall’ organizzazione che funge da partner di risorsa. Gli Account Federation Server generano dei cookies di autenticazione per mantenere sempre attivo lo status di logon. Tali cookie di autenticazione permettono di estendere le funzionalità SSO (Single Sign On) e in questo caso utenti diversi che visitano più volte una pagina Web-based nella rete dei partner di risorsa, non dovranno reinserire le credenziali.
AD DS domain controller: Il server che mantiene nel suo storage tutti gli account utente dell’organizzazione.
Federation Service Proxy: Il Federation Service Proxy agisce come proxy per gli accessi utente ai server federativi che si trovano nella rete Intranet. I Federation Service Proxy operano anche come proxy per i token di sicurezza che sono emessi dall’ Account Federation Server per la propria organizzazione e per i token destinati a partner di risorsa. Il Federation Service Proxy è un componente opzionale.
AD FS Web Agent: AD FS Web Agent gestisce i token di sicurezza e i cookie di autenticazione che vengono inviati a un server web. Il server Web ha bisogno di stabilire un rapporto di fiducia con un servizio federativo in modo che tutti i token di autenticazione provengano da quello stesso servizio. ADFS Web Agent può creare dei cookie HTTP nel browser del client per facilitare l’autentica Web-based SSO.
Resource Federation Server: I Resource Federation Server si trovano presso l’organizzazione del partner di risorsa. Questi server convalidano i token di sicurezza che vengono rilasciati dai server dell’account partner. Questi server possono anche rilasciare i token di protezione utilizzati per accedere alle applicazioni basate sul Web presenti nella rete dei partner di risorsa. Inoltre, i Resource federation Server rilasciano i cookies di autenticazione per gli utenti di un’organizzazione partner account. Tali cookie di autenticazione supportano le funzionalità SSO. Pertanto, gli utenti non devono accedere nuovamente al server di federazione sulla rete dell’account partner quando tentano di accedere a diverse applicazioni basate sul Web, presenti nell’organizzazione.
SCENARIO B2B
In uno scenario B2B, un utente dell’organizzazione partner account utilizza un browser Web per accedere a un’applicazione Web che si trova nell’organizzazione del partner di risorsa attraverso una sessione Transport Layer Security / Secure Sockets Layer (TLS / SSL) PUNTO 1. Esiste già un Trust federativo tra le due organizzazioni. L’applicazione Web è configurata per consentire l’accesso solo a chi è autenticato e l’utente in questo caso appartiene a una diversa organizzazione.
L’applicazione Web reindirizza il browser Web al server AD FS dell’ organizzazione partner di risorsa PUNTO2. Il server AD FS dell’organizzazione del partner di risorsa verifica se l’account utente proviene dal partner account federato. Il server AD FS risponde al browser Web per richiedere un token di protezione dal server AD FS sito nell’ organizzazione del partner account. Pertanto, il browser viene reindirizzato al server di AD FS dell’organizzazione del partner account PUNTO3.
L’utente può essere autenticato tramite l’autenticazione integrata di Windows sfruttando le credenziali attualmente utilizzate sul suo desktop. In alternativa, l’utente può essere autenticato, fornendo le proprie credenziali al server di AD FS. Il server AD FS tramite il database Active Directory covalida le credenziali dell’ utente PUNTO4. Il server AD FS esamina le configurazioni del Trust federativo e determina le informazioni che devono essere incluse nel token di protezione. Il server di AD FS crea quindi un token di protezione Security Assertion Markup Language (SAML), con le informazioni richieste e invia il token al browser web PUNTO5.
Il browser Web invia il token di protezione al server AD FS dell’organizzazione del partner di risorsa. Il server AD FS verifica il token di protezione e crea un nuovo token di sicurezza che può essere utilizzato dall’applicazione web. Il server AD FS quindi invia il nuovo token di sicurezza al browser web dell’utente PUNTO6.
Il browser Web presenta il token di protezione al server Web dell’organizzazione del partner di risorsa PUNTO7. Il server Web accetta il token di protezione e l’utente dell’organizzazione dell’account partner ottiene l’accesso alle applicazioni web.
SCENARIO WEB SSO
In uno scenario Web SSO, un’organizzazione distribuisce un’applicazione Web su una Perimeter Network. Questa applicazione Web dovrebbe essere disponibile per i dipendenti sulla rete interna, i dipendenti al di fuori della rete interna, e per i non-dipendenti.
In un possibile scenario di questo tipo, l’organizzazione distribuisce un’infrastruttura di Active Directory per tutti i dipendenti sulla rete interna. Per motivi di sicurezza, l’organizzazione può implementare un’altra foresta di Active Directory sulla Perimeter Network per tutti i dipendenti al di fuori della rete interna. Inoltre, l’organizzazione può implementare Active Directory Lightweight Directory Services (AD LDS) per mantenere gli account utente per tutti i non-dipendenti che hanno bisogno di accedere all’applicazione.
L’organizzazione può implementare un trust unidirezionale dalla foresta di Active Directory della Perimeter Network verso la foresta della intranet. Ciò consente al pool di applicazioni e ai servizi che si trovano nella Perimeter Network di agire come account di servizio nella rete Intranet. I dipendenti interni utilizzerano l’autenticazione integrata sfruttando gli account residenti in Active Directory. I Dipendenti remoti utilizzeranno l’ autenticazione TLS / SSL client per autenticarsi in Active Directory. I non dipendenti utilizzeranno credenziali di accesso memorizzate in AD LDS.
L’ autenticazione tramite AD FS è indipendente dal tipo di account utente o da un meccanismo di autenticazione. Il token di protezione viene generato e quindi consegnato all’applicazione per autorizzare le richieste utente.
segue nella parte due…
Fonti utilizzate: Microsoft
The Active Directory Federation Services in Windows Server 2008 (parte1) by My Beautiful Place, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Italy License.
