Le attestazioni sono dichiarazioni relative agli utenti (ad esempio nome, identità, chiave, gruppo, privilegio o funzionalità), riconosciute da entrambi i partner di una federazione Active Directory Federation Services (ADFS) e utilizzate a scopo di autorizzazione in un'applicazione.

Il servizio federativo ADFS esegue la negoziazione di trust tra numerose entità diverse ed è progettato per consentire lo scambio trusted di attestazioni contenenti valori arbitrari. Il partner di destinazione (ad esempio un partner risorse) utilizza quindi tali attestazioni per prendere decisioni relative alle autorizzazioni.

Gli scenari possibili per il flusso di attestazioni attraverso il servizio federativo sono tre:

  • Il servizio federativo dell'account riceve le attestazioni dall'archivio account e le invia al partner risorse.

  • Il servizio federativo della risorsa riceve le attestazioni dal partner account e le invia all'applicazione della risorsa.

  • Il servizio federativo riceve le attestazioni dall'archivio account e le invia all'applicazione della risorsa.

È possibile configurare il servizio federativo in modo che svolga tutti e tre i ruoli indicati e, pertanto, facilitare i tre flussi di comunicazione mediante un unico servizio federativo.

Il servizio federativo supporta tre tipi di attestazioni, ovvero attestazioni d'identità, attestazioni basate su gruppo e attestazioni personalizzate. Nella tabella seguente viene descritto in modo più dettagliato ognuno di questi tipi.

Tipo di attestazione Descrizione

Identità

In ADFS i tipi UPN, Posta elettronica e Nome comune vengono definiti tipi di attestazione d'identità.

  • UPN: indica un nome dell'entità utente (UPN) con autenticazione Kerberos, ad esempio utente@areaautenticazione. Solo un'attestazione può essere di tipo UPN. Anche se è necessario comunicare più valori UPN, solo un'attestazione può essere di questo tipo. È tuttavia possibile configurare UPN aggiuntivi come tipi di attestazione personalizzata.

  • Posta elettronica: indica nomi di posta elettronica conformi alla RFC (Request for Comments) 2822 nel formato utente@dominio. Solo un'attestazione può essere di tipo Posta elettronica. Anche se è necessario comunicare più valori di tipo Posta elettronica, solo un'attestazione può essere di questo tipo. È tuttavia possibile configurare valori di tipo Posta elettronica aggiuntivi come tipi di attestazione personalizzata.

  • Nome comune: indica una stringa arbitraria utilizzata per la personalizzazione, ad esempio John Smith o Dipendente della Tailspin Toys. Solo un'attestazione può essere di tipo Nome comune. Poiché non esiste alcun meccanismo per garantire l'univocità dell'attestazione basata su nome comune, è necessario prestare attenzione quando si utilizza questo tipo di attestazione per decisioni relative alle autorizzazioni.

Gruppo

Indica l'appartenenza a un gruppo o a un ruolo. Gli amministratori definiscono attestazioni singole con il tipo di gruppo "Attestazioni basate su gruppo". È ad esempio possibile definire l'insieme di attestazioni basate su gruppo [Sviluppatore, Tester, Program manager]. Ogni attestazione basata su gruppo costituisce un'unità amministrativa separata per il popolamento e il mapping di attestazioni. Il valore di un'attestazione basata su gruppo può essere paragonato a un valore booleano che indica l'appartenenza.

Personalizzata

Indica un'attestazione che contiene informazioni personalizzate relative a un utente, ad esempio il numero ID del dipendente.

Se in un token sono presenti più tipi di attestazione d'identità, le relative priorità verranno assegnate nell'ordine seguente:

  1. UPN

  2. Posta elettronica

  3. Nome comune

Per l'emissione di un token, è necessaria la presenza di almeno uno di questi tipi di attestazione d'identità.

Mapping di attestazioni

ADFS utilizza il protocollo WS-F PRP (WS-Federation Passive Requestor Protocol), che trasporta le attestazioni nei token di sicurezza emessi dal servizio federativo. Le attestazioni vengono popolate inizialmente dagli archivi account di Servizi di dominio Active Directory o di Active Directory Lightweight Directory Services (AD LDS).

Il servizio federativo può eseguire il mapping di attestazioni in ingresso o in uscita di un partner federativo. Il mapping di attestazioni consiste nell'azione di associazione, rimozione, filtraggio o trasferimento di attestazioni in ingresso all'interno di attestazioni in uscita. Il mapping di attestazioni può essere diverso per ogni partner federativo. La definizione del popolamento e del mapping di queste attestazioni è importante per la configurazione della federazione. Per i mapping di attestazioni vengono utilizzati confronti tra stringhe in cui viene fatta distinzione tra maiuscole e minuscole. Nella figura seguente viene illustrato il processo di mapping di attestazioni.

Il processo di mapping richieste

Insiemi di attestazioni di organizzazione

Viene eseguito il mapping di tutte le attestazioni in ingresso alle attestazioni di organizzazione. Le attestazioni di organizzazione sono attestazioni in formato intermedio o normalizzato all'interno dello spazio dei nomi di un'organizzazione. Tutte le azioni interne del servizio federativo vengono eseguite sull'insieme di attestazioni di organizzazione. Le attestazioni di organizzazione vengono utilizzate dalle applicazioni della risorsa.

Con le attestazioni di organizzazione, non è necessario amministrare singolarmente i mapping tra due organizzazioni qualsiasi che devono comunicare. Ogni organizzazione definisce un mapping singolo in uscita o in ingresso per le proprie attestazioni di organizzazione, semplificando in tal modo l'amministrazione di ADFS. Se ad esempio la federazione comprende:

x partner account

y applicazioni della risorsa

includerà x + y mapping di attestazioni.

Si tratta di una quantità ridotta rispetto alla quantità potenziale di x × y mapping di attestazioni. Come esempio concreto, si supponga che un servizio federativo comprenda:

3 partner account

7 applicazioni della risorsa

Quando il mapping viene eseguito direttamente dalle attestazioni in ingresso a quelle in uscita, la federazione richiede solo 10 mapping di attestazioni rispetto ai 21 mapping di attestazioni potenziali.

Posta elettronica

Per i tipi di attestazione basata su posta elettronica viene eseguito sempre il mapping a tipi di attestazione basata su posta elettronica. Durante questo processo, nel servizio federativo dell'account è possibile eseguire il mapping del suffisso di dominio a un valore costante proteggendo in tal modo un'organizzazione partner dalla divulgazione accidentale di informazioni sulla struttura della foresta interna a un'altra organizzazione. Nel servizio federativo della risorsa è possibile filtrare il suffisso di dominio in base a un elenco di valori costanti.

Nell'esempio seguente viene descritta una federazione ADFS tra due organizzazioni, Tailspin Toys e Adventure Works, che rappresentano rispettivamente il partner account e il partner risorse.

  • Tailspin Toys, in qualità di servizio federativo dell'account, esegue il mapping dell'attestazione di organizzazione basata su posta elettronica all'attestazione basata su posta elettronica in uscita per Adventure Works. Durante il processo viene eseguito il mapping di tutti i suffissi di posta elettronica a tailspintoys.com. Supponendo che l'attestazione di organizzazione basata su posta elettronica sia e-mail=jsmith@sales.tailspintoys.com, l'attestazione basata su posta elettronica in uscita sarà e-mail=jsmith@tailspintoys.com.

  • Adventure Works, in qualità di servizio federativo della risorsa, esegue il mapping dell'attestazione basata su posta elettronica in ingresso di Tailspin Toys all'attestazione di organizzazione basata su posta elettronica e, durante il processo, l'elenco di suffissi viene filtrato in base a tailspintoys.com. Un'attestazione basata su posta elettronica in ingresso di Tailspin Toys corrispondente a e-mail=jsmith@tailspintoys.com verrà pertanto accettata, mentre un'attestazione basata su posta elettronica in ingresso di Tailspin Toys corrispondente a e-mail=jsmith@adventure-works.com verrà rifiutata.

UPN

Per i tipi di attestazione basata su UPN viene eseguito sempre il mapping a tipi di attestazione basata su UPN. Queste attestazioni vengono sottoposte al filtraggio e al mapping dei suffissi in modo analogo alle attestazioni basate su posta elettronica. Poiché tuttavia Servizi di dominio Active Directory consente l'utilizzo di UPN senza il simbolo @, il servizio federativo dell'account aggiunge il simbolo @, seguito dal suffisso nel caso in cui sia stato definito un mapping di suffissi UPN. Se invece viene passato un suffisso qualsiasi, il servizio federativo trasmette l'UPN così com'è, senza il simbolo @. Sul lato risorsa, se sono consentiti tutti i suffissi UPN, l'UPN senza il simbolo @ viene accettato. Se invece è consentito un suffisso UPN specifico, l'UPN senza il simbolo @ viene rifiutato.

Nome comune

Per i tipi di attestazione basata su nome comune viene eseguito sempre il mapping a tipi di attestazione basata su nome comune. Queste attestazioni non sono soggette a ulteriori regole.

Personalizzata

Per i tipi di attestazione personalizzata viene eseguito sempre il mapping ad altri tipi di attestazione personalizzata. Nel caso di un insieme di attestazioni in ingresso corrispondente a (UPN, Custom=[NumeroDipendente, IDContribuente]) e di un insieme di attestazioni di organizzazione corrispondente a (UPN, Custom=[Dipendente, NumeroPrevidenzaSociale]), è ad esempio possibile creare mapping personalizzati da NumeroDipendente a Dipendente e da IDContribuente a NumeroPrevidenzaSociale.

Gruppo

Per i tipi di attestazione basata su gruppo viene eseguito sempre il mapping ad altri tipi di attestazione basata su gruppo. Nel caso di un insieme di attestazioni in ingresso corrispondente a (UPN, Group=[Uno, Due, Tre]) e di un insieme di attestazioni di organizzazione corrispondente a (UPN, Group=[X,Y,Z]), è ad esempio possibile creare mapping personalizzati da Uno a Y, da Due a X e da Tre a Z.

Mapping da gruppo a UPN

Oltre ai mapping standard descritti nelle sezioni precedenti, è possibile utilizzare un mapping di attestazioni speciale da gruppo a UPN. Questo tipo di mapping è supportato nel servizio federativo della risorsa solo quando le attestazioni in ingresso provengono da un partner account. In questo caso, non viene eseguito il mapping dei tipi di attestazione basata su UPN a tipi di attestazione basata su UPN, bensì viene specificato un elenco ordinato di mapping di attestazioni da gruppo a UPN.

L'elenco da gruppo a UPN potrebbe essere ad esempio il seguente:

  1. Da Dev a developers@internal.tailspintoys.com

  2. Da Test a testers@internal.tailspintoys.com

  3. Da PM a progmgrs@internal.tailspintoys.com

Nel caso di un insieme di attestazioni in ingresso corrispondente a (Common name=John Smith, Group=[Dev]), l'insieme di attestazioni di organizzazione contiene (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Tenere presente che si tratta di un elenco ordinato. Un insieme di attestazioni corrispondente a (Common name=John Smith, Group=[Dev,PM]) avrà pertanto come risultato (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Se inoltre l'attestazione in ingresso include un UPN, quest'ultimo verrà sovrascritto. Questa regola di mapping speciale supporta gli account delle risorse basati su gruppo che accedono a risorse legacy. L'ordine dei mapping da gruppo a UPN è specificato nei criteri di attendibilità per il servizio federativo.

Controllo di attestazioni

Alcune attestazioni basate su gruppo e personalizzate possono essere designate come controllabili. Quando il controllo è abilitato, è possibile esporre il nome dell'attestazione nel registro eventi di sicurezza ma il valore dell'attestazione viene omesso. Il numero di previdenza sociale è un esempio di attestazione controllabile. In questo caso, il nome dell'attestazione viene esposto ma il valore del numero effettivo archiviato nell'attestazione viene omesso. Il valore dell'attestazione non viene controllato durante la creazione o il mapping dell'attestazione.

Nota

I tipi di attestazione d'identità sono sempre controllabili.

Vedere anche


Argomenti della Guida