Quando si pianifica una collaborazione federativa tra organizzazioni utilizzando Active Directory Federation Services (ADFS), è innanzitutto necessario stabilire se la propria organizzazione ospiterà una risorsa Web a cui è possibile accedere da altre organizzazioni tramite Internet o viceversa. Questa decisione influisce sulle modalità di distribuzione di ADFS e costituisce un aspetto fondamentale nella pianificazione dell'infrastruttura ADFS.
Per le progettazioni federative, ad esempio quelle di tipo Web SSO federativo e Web SSO federativo con trust tra foreste ma non di tipo Web SSO, in ADFS vengono utilizzati rispettivamente i termini "partner account" e "partner risorse" per distinguere l'organizzazione che ospita gli account (partner account) da quella che ospita le risorse basate sul Web (partner risorse). Il termine "relazione di trust federativa" viene utilizzato in ADFS per caratterizzare la relazione unidirezionale non transitiva stabilita tra il partner account e il partner risorse.
Per ulteriori informazioni sulle progettazioni di ADFS, vedere Informazioni sulle progettazioni federative.
Nelle sezioni seguenti vengono illustrati alcuni concetti relativi ai partner account e ai partner risorse.
Partner account
Nella relazione di trust federativa un partner account rappresenta l'organizzazione in cui sono archiviati fisicamente gli account utente, in un archivio di Servizi di dominio Active Directory o di Active Directory Lightweight Directory Services (AD LDS). Il partner account è responsabile della raccolta e dell'autenticazione delle credenziali di un utente, della creazione delle attestazioni relative a tale utente e dell'inserimento di tali attestazioni nei token di sicurezza. Tali token possono essere inviati attraverso una relazione di trust federativa per eseguire l'accesso a risorse basate sul Web che si trovano nell'organizzazione partner risorse.
In altre parole, un partner account rappresenta l'organizzazione a cui appartengono gli utenti per i quali il servizio federativo sul lato account rilascia i token di sicurezza. Il servizio federativo nell'organizzazione partner account esegue l'autenticazione degli utenti locali e crea i token di sicurezza utilizzati dal partner risorse per prendere decisioni relative alle autorizzazioni.
In relazione a Servizi di dominio Active Directory, il partner account in ADFS è concettualmente equivalente a una foresta singola di Servizi di dominio Active Directory i cui account devono accedere alle risorse che risiedono fisicamente in un'altra foresta. Gli account presenti in questa foresta di esempio possono accedere alle risorse disponibili nella relativa foresta solo se tra le due foreste esiste una relazione di trust esterno o una relazione di trust tra foreste e sono state impostate le autorizzazioni appropriate per le risorse a cui gli utenti tentano di accedere.
 | Nota |
|
Questo esempio è stato riportato solo per sottolineare l'analogia concettuale della relazione tra le organizzazioni partner account e partner risorse in ADFS con la relazione tra una foresta degli account e una foresta delle risorse in Servizi di dominio Active Directory. Per il funzionamento di ADFS non sono necessari trust esterni e trust tra foreste. |
Creare attestazioni da inviare al partner risorse
Un'attestazione è una dichiarazione di un server (ad esempio nome, identità, chiave, gruppo, privilegio o funzionalità) relativa a un client. Le attestazioni create dal partner account vengono utilizzate dal servizio federativo del partner risorse. Nell'elenco seguente vengono descritti i diversi tipi di attestazione che è possibile configurare nel partner account sul lato server federativo di risorsa.
-
Attestazione basata su UPN
Quando si configura il partner account, è possibile specificare un elenco di domini e suffissi del nome dell'entità utente (UPN) accettati dal partner account. Se viene ricevuta un'identità UPN in cui la parte relativa al dominio non è presente nell'elenco, la richiesta verrà rifiutata.
-
Attestazione basata su posta elettronica
Quando si configura il partner account, è possibile specificare un elenco di domini e suffissi di posta elettronica accettati dal partner account. Come nel caso di un'attestazione basata su UPN, se viene ricevuta un'identità basata su posta elettronica in cui la parte relativa al dominio non è presente nell'elenco, la richiesta verrà rifiutata.
-
Attestazione basata su nome comune
Quando si configura il partner account, è possibile specificare se le attestazioni basate su nome comune possono essere ricevute dal partner account. Non è possibile eseguire il mapping di questo tipo di attestazione, che viene semplicemente passata al partner account nel caso in cui sia abilitata.
-
Attestazioni basate su gruppo
Quando si configura il partner account, è possibile specificare un insieme di attestazioni basate su gruppo in ingresso accettate dal partner. È quindi possibile associare ogni gruppo in ingresso valido a un'attestazione di organizzazione basata su gruppo. In questo modo viene creato un mapping del gruppo. Se viene rilevato un gruppo in ingresso privo di mapping, verrà ignorato.
-
Attestazioni personalizzate
Quando si configura il partner account, è possibile specificare un insieme di nomi in ingresso di attestazioni personalizzate accettate dal partner. È quindi possibile eseguire il mapping di ogni nome in ingresso valido a un'attestazione di organizzazione personalizzata. In questo modo viene creato un mapping del nome. Se viene rilevata un'attestazione personalizzata in ingresso priva di mapping, verrà ignorata.
Partner risorse
Un partner risorse è il secondo partner organizzativo nella relazione di trust federativa. Tale partner è l'organizzazione in cui risiedono i server Web abilitati per ADFS che ospitano una o più applicazioni basate sul Web, ovvero le risorse. Il partner risorse stabilisce una relazione di trust con il partner account per eseguire l'autenticazione degli utenti. Per prendere decisioni relative alle autorizzazioni, il partner risorse utilizza pertanto le attestazioni inserite nei token di sicurezza provenienti dagli utenti del partner account.
In altre parole, un partner risorse rappresenta l'organizzazione i cui server Web abilitati per ADFS sono protetti dal servizio federativo sul lato risorse. Il servizio federativo del partner risorse utilizza i token di sicurezza creati dal partner account per prendere decisioni relative alle autorizzazioni dei server Web abilitati per ADFS che si trovano nel partner risorse.
Affinché un server Web abilitato per ADFS nell'organizzazione partner risorse svolga la funzione di risorsa di ADFS, è necessario installare il componente Agente Web ADFS. I server Web che svolgono la funzione di risorsa di ADFS possono ospitare sia applicazioni in grado di riconoscere attestazioni che applicazioni basate su token Windows NT.
| Nota |
|
Se l'applicazione ospitata dal server Web abilitato per ADFS è un'applicazione basata su token Windows NT, potrebbe essere necessario un account della risorsa per la foresta di Servizi di dominio Active Directory nell'organizzazione partner risorse. |
In relazione a Servizi di dominio Active Directory, il partner risorse è concettualmente equivalente a una foresta singola le cui risorse sono rese disponibili, tramite una relazione di trust esterno o una relazione di trust tra foreste, per gli account archiviati fisicamente in un'altra foresta.
| Nota |
|
Questo esempio è stato riportato solo per sottolineare l'analogia concettuale della relazione tra le organizzazioni partner account e partner risorse in ADFS con la relazione tra una foresta di account e una foresta di risorse in Servizi di dominio Active Directory. Per il funzionamento di ADFS non sono necessari trust esterni e trust tra foreste. |
Utilizzare attestazioni provenienti dal partner account
Un partner risorse utilizza le attestazioni create e inserite nei token di sicurezza dal servizio federativo del partner account. Nell'elenco seguente vengono descritte le possibili modalità di invio delle attestazioni al partner risorse.
-
Attestazione basata su UPN
Quando si configura il partner risorse, è possibile specificare se un'attestazione basata su UPN deve essere inviata al partner risorse. È inoltre possibile specificare un mapping di suffissi in modo che ogni suffisso venga mappato a un suffisso in uscita specificato. È ad esempio possibile eseguire il mapping di julianp@sales.tailspintoys.com a julianp@tailspintoys.com. Si noti che è possibile specificare un unico suffisso in uscita.
-
Attestazione basata su posta elettronica
Quando si configura il partner risorse, è possibile specificare se un'attestazione basata su posta elettronica deve essere inviata al partner risorse. È inoltre possibile specificare un mapping di suffissi in modo che ogni suffisso venga mappato a un suffisso specificato. È ad esempio possibile eseguire il mapping di vernettep@sales.tailspintoys.com a vernettep@tailspintoys.com. Si noti che è possibile specificare un unico suffisso in uscita.
-
Attestazione basata su nome comune
Quando si configura il partner risorse, è possibile specificare se le attestazioni basate su nome comune possono essere inviate al partner risorse. Non è possibile eseguire il mapping di questo tipo di attestazione, che viene semplicemente passata al partner risorse nel caso in cui sia abilitata.
-
Attestazioni basate su gruppo
Quando si configura il partner risorse, è possibile specificare un insieme di attestazioni basate su gruppo in uscita che verranno accettate dal partner risorse. È quindi possibile associare ogni attestazione valida di questo tipo alle attestazioni di organizzazione basate su gruppo. In questo modo viene creato un insieme di mapping relativi al gruppo. Non vengono create attestazioni di organizzazione basate su gruppo che non corrispondono a un'attestazione basata su gruppo in uscita.
-
Attestazioni personalizzate
Quando si configura il partner risorse, è possibile specificare un insieme di attestazioni personalizzate in uscita accettate dal partner risorse. È possibile eseguire il mapping di ogni attestazione valida di questo tipo a un'attestazione di organizzazione personalizzata. In questo modo viene creato un insieme di mapping relativi al nome. Non vengono create attestazioni di organizzazione personalizzate che non corrispondono a un'attestazione personalizzata in uscita.
Consenti privacy identità avanzata
L'opzione Consenti privacy identità avanzata è un'impostazione facoltativa che può essere configurata nei criteri di attendibilità di un partner risorse. Se l'opzione Consenti privacy identità avanzata è abilitata, viene eseguito l'hashing della parte relativa al nome utente delle attestazioni basate su UPN e su posta elettronica in uscita e il nome comune viene sostituito con un valore casuale.
Lo scopo di questa funzionalità è prevenire le situazioni seguenti:
-
Individuazione della correlazione tra le attestazioni d'identità e le informazioni che consentono l'identificazione personale dell'utente da parte del partner risorse.
-
Accordo illecito tra i partner al fine di individuare la correlazione tra le attestazioni d'identità e le informazioni che consentono l'identificazione personale dell'utente. Questa impostazione consente di creare un hash univoco per ogni partner in modo che i valori delle attestazioni d'identità siano diversi tra partner di aree di autenticazione trusting diverse ma coerenti nelle sessioni relative a un partner singolo.
-
Attacchi con dizionario semplici contro l'hash tramite il salt del valore utente con i dati presenti nei criteri di attendibilità, che non sono noti ai partner risorse.