Applicazioni relying party
Aggiornamento: 19 giugno 2015
Si applica a: Azure
Un'applicazione relying party, nota anche come applicazione in grado di riconoscere attestazioni o applicazione basata su attestazioni, è un'applicazione o un servizio che si basa sulle attestazioni per l'autenticazione. In Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS), un'applicazione relying party è un sito Web, un'applicazione o un servizio che usa ACS per implementare l'autenticazione federata.
È possibile creare e configurare manualmente le applicazioni di relying party usando il portale di gestione ACS o a livello di codice usando il servizio di gestione ACS.
Nel portale di gestione di ACS l'applicazione relying party aggiunta e configurata è una rappresentazione logica del sito Web, dell'applicazione o del servizio che considera attendibile uno spazio dei nomi specifico Controllo di accesso. È possibile aggiungere e configurare molte applicazioni di relying party in ogni spazio dei nomi Controllo di accesso.
Configurazione nel portale di gestione ACS
È possibile usare il portale di gestione di ACS per configurare le proprietà seguenti di un'applicazione relying party:
Modalità
Area di autenticazione e URL restituito
URL errori (facoltativo)
Formato token
Criteri di crittografia token
Durata del token
Provider di identità
Gruppi di regole
Firma di token
Crittografia dei token
Modalità
La proprietà Modalità determina se le impostazioni dell'applicazione relying party sono configurate manualmente o se si specifica un documento metadati WS-Federation che definisce le impostazioni dell'applicazione.
Un documento metadati WS-Federation include in genere l'area di autenticazione e l'URL restituito di un'applicazione. Può includere anche un certificato di crittografia facoltativo, usato per crittografare i token emessi da ACS per l'applicazione. Se viene specificato un documento WS-Federation e i metadati contengono un certificato di crittografia, l'impostazione criteri di crittografia dei token viene impostata per impostazione predefinita su Richiedi crittografia. Se il valore dell'impostazione Criterio di crittografia token è Richiedi crittografia, ma il documento metadati WS-Federation non include alcun certificato di crittografia, sarà necessario caricare manualmente un certificato di crittografia.
Se l'applicazione relying party è integrata con Windows Identity Foundation (WIF), WIF creerà automaticamente un documento metadati WS-Federation per l'applicazione.
Area di autenticazione e URL restituito
La proprietà Realm definisce l'URI in cui i token rilasciati da ACS sono validi. L'URL restituito (noto anche come indirizzo ReplyTo) definisce l'URL a cui vengono inviati i token rilasciati da ACS. Quando viene richiesto un token per l'accesso all'applicazione relying party, ACS rilascia il token solo quando l'area di autenticazione nella richiesta di token corrisponde all'area di autenticazione dell'applicazione relying party.
Importante
In ACS i valori dell'area di autenticazione sono distinzione tra maiuscole e minuscole.
Nel portale di gestione di ACS è possibile configurare solo un'area di autenticazione e un URL restituito in ogni spazio dei nomi Controllo di accesso. Nei casi più semplici l'area di autenticazione e l'URL restituito sono identici. Ad esempio, se l'URI radice dell'applicazione è https://contoso.com, l'URL di autenticazione e restituzione dell'applicazione relying party è https://contoso.com.
Per configurare più url restituiti (indirizzo ReplyTo) per un'applicazione relying party, usare l'entità RelyingPartyAddress nel servizio di gestione ACS.
Quando viene richiesto un token da ACS o un token viene inviato a ACS da un provider di identità, ACS confronta il valore dell'area di autenticazione nella richiesta di token ai valori dell'area di autenticazione per le applicazioni relying party. Se la richiesta del token usa WS-Federation protocollo, ACS usa il valore dell'area di autenticazione nel parametro wtrealm . Se il token usa il protocollo OAuth WRAPPING, ACS usa il valore dell'area di autenticazione nel parametro applies_to . Se ACS trova un'area di autenticazione corrispondente nelle impostazioni di configurazione per un'applicazione relying party, crea un token che autentica l'utente all'applicazione relying party e invia il token all'URL restituito.
Il processo è simile quando la relying party ha più di un URL restituito. ACS ottiene l'URL di reindirizzamento dal parametro wreply . Se l'URL di reindirizzamento è uno degli URL restituiti per l'applicazione relying party, ACS invierà la risposta a quell'URL.
Per i valori dell'area di autenticazione viene fatta distinzione tra maiuscole e minuscole. Il token viene emesso solo se i valori dell'area di autenticazione sono identici o se il valore dell'area di autenticazione per l'applicazione relying party è un prefisso dell'area di autenticazione nella richiesta di token. Ad esempio, il valore dell'area di autenticazione dell'applicazione relying party di http://www.fabrikam.com corrisponde al valore dell'area di autenticazione della richiesta di token di http://www.fabrikam.com/billing, ma non corrisponde a un'area di autenticazione della richiesta di token v di https://fabrikam.com.
URL errori (facoltativo)
L'URL di errore specifica un URL a cui ACS reindirizza gli utenti se si verifica un errore durante il processo di accesso. Si tratta di una proprietà facoltativa dell'applicazione relying party.
Il valore dell'URL di errore può essere una pagina personalizzata ospitata dall'applicazione relying party, ad esempio http://www.fabrikam.com/billing/error.aspx. Nell'ambito del reindirizzamento, ACS fornisce informazioni dettagliate sull'errore dell'applicazione relying party come parametro URL HTTP con codifica JSON. La pagina di errore personalizzata può essere impostata in modo da interpretare le informazioni sull'errore con codifica JSON, eseguire il rendering dell'effettivo messaggio di errore ricevuto e/o visualizzare testo statico della Guida.
Per altre informazioni sull'utilizzo dell'URL di errore, vedere Esempio di codice: ASP.NET Semplice MVC 2.
Formato token
La proprietà Formato token determina il formato dei token che ACS rilascia per l'applicazione relying party. ACS può inviare token SAML 2.0, SAML 1.1, SWT o JWT. Per altre informazioni sui formati di token, vedere Formati di token supportati in ACS.
ACS usa protocolli standard per restituire i token a un'applicazione Web o a un servizio. Quando più di un protocollo è supportato per un formato di token, ACS usa lo stesso protocollo usato per la richiesta di token. ACS supporta le combinazioni di formato/protocollo token seguenti:
ACS può restituire token SAML 2.0 usando WS-Trust e protocolli di WS-Federation.
ACS può restituire token SAML 1.1 usando WS-Federation e protocolli di WS-Trust correlati.
ACS può restituire token SWT usando protocolli WS-Federation, WS-Trust, OAuth-WRAPPING e OAuth 2.0.
ACS può emettere e restituire token JWT usando protocolli WS-Federation, WS-Trust e OAuth 2.0.
Per altre informazioni sui protocolli standard usati dall'ACS, vedere Protocolli supportati in ACS.
Quando si sceglie un formato di token, valutare il modo in cui lo spazio dei nomi Controllo di accesso firma i token che generano problemi. Tutti i token rilasciati da ACS devono essere firmati. Per altre informazioni, vedere Firma token.
Occorre anche decidere se si vuole che i token siano crittografati. Per altre informazioni, vedere Criteri di crittografia dei token.
Criteri di crittografia token
I criteri di crittografia dei token determinano se i token che ACS generano problemi per l'applicazione relying party vengono crittografati. Per richiedere la crittografia, selezionare il valore Richiedi crittografia.
In ACS è possibile configurare un criterio di crittografia solo per i token SAML 2.0 o SAML 1.1. ACS non supporta la crittografia dei token SWT o JWT.
ACS crittografa i token SAML 2.0 e SAML 1.1 usando un certificato X.509 contenente una chiave pubblica (file con estensione cer). Questi token crittografati vengono quindi decrittografati tramite una chiave privata in possesso dell'applicazione relying party. Per altre informazioni su come ottenere e usare i certificati di crittografia, vedere Certificati e chiavi.
La configurazione di un criterio di crittografia nei token rilasciati da ACS è facoltativa. È tuttavia necessario configurare un criterio di crittografia quando l'applicazione relying party è un servizio Web che usa token proof-of-possession sul protocollo WS-Trust. Questo scenario specifico non funziona correttamente senza token crittografati.
Durata del token
La proprietà Durata token specifica l'intervallo di tempo (in secondi) durante il quale il token di sicurezza che ACS rilascia all'applicazione relying party è valido. Il valore predefinito è 600 (10 minuti). In ACS il valore di durata del token deve essere compreso tra zero (0) e 86400 (24 ore) inclusivo.
Provider di identità
La proprietà Provider di identità specifica i provider di identità che possono inviare attestazioni all'applicazione relying party. Questi provider di identità vengono visualizzati nella pagina di accesso di ACS per l'applicazione Web o il servizio. Tutti i provider di identità configurati nella sezione Provider di identità del portale di ACS vengono visualizzati nell'elenco dei provider di identità. Per aggiungere un provider di identità all'elenco, fare clic su Provider di identità.
Ogni applicazione relying party può essere associata a zero o più provider di identità. Le applicazioni di relying party in uno spazio dei nomi Controllo di accesso possono essere associate allo stesso provider di identità o a diversi provider di identità. Se non si selezionano provider di identità per un'applicazione relying party, è necessario configurare un'autenticazione diretta con ACS per l'applicazione relying party. Ad esempio, è possibile usare le identità del servizio per configurare un'autenticazione diretta. Per altre informazioni, vedere Identità del servizio.
Gruppi di regole
La proprietà Gruppi di regole determina le regole usate dall'applicazione relying party durante l'elaborazione delle attestazioni.
Ogni applicazione della relying party di ACS deve essere associata a almeno un gruppo di regole. Se una richiesta di token corrisponde a un'applicazione relying party senza gruppi di regole, ACS non rilascia un token per l'applicazione Web o il servizio.
Tutti i gruppi di regole configurati nella sezione Gruppi di regole del portale ACS vengono visualizzati nell'elenco dei gruppi di regole. Per aggiungere un gruppo di regole all'elenco, fare clic su Gruppi di regole.
Quando si aggiunge una nuova applicazione relying party nel portale di gestione ACS, l'opzione Crea nuovo gruppo di regole è selezionata per impostazione predefinita. È consigliabile creare un nuovo gruppo di regole per la nuova applicazione relying party, ma è anche possibile associare l'applicazione relying party a un gruppo di regole esistente. A tale scopo, deselezionare l'opzione Crea nuovo gruppo di regole e selezionare il gruppo di regole desiderato.
È possibile associare un'applicazione relying party con più di un gruppo di regole e associare un gruppo di regole a più di una applicazione relying party. Se un'applicazione relying party è associata a più di un gruppo di regole, ACS valuta in modo ricorsivo le regole in tutti i gruppi di regole come se fossero regole in un singolo gruppo di regole.
Per altre informazioni sulle regole e sui gruppi di regole, vedere Rule Groups and Rules.For more information about rules and rule groups, see Rule Groups and Rules.
Firma di token
La proprietà Impostazioni firma token specifica la modalità di firma dei token di sicurezza firmati da ACS. Tutti i token emessi da ACS devono essere firmati.
Le opzioni di firma dei token disponibili dipendono dal Formato token dell'applicazione relying party. Per altre informazioni sui formati di token, vedere Formato token.
Token SAML: usare un certificato X.509 per firmare i token.
Token SWT: usare una chiave simmetrica per firmare i token.
Token JWT: usare un certificato X.509 o una chiave simmetrica per firmare i token.
Opzioni del certificato X.509. Le opzioni seguenti sono disponibili per i token firmati con un certificato x.509.
Usare il certificato dello spazio dei nomi del servizio (standard): se si seleziona questa opzione, ACS usa il certificato per lo spazio dei nomi Controllo di accesso per firmare i token SAML 1.1 e SAML 2.0 per l'applicazione relying party. Usare questa opzione se si prevede di automatizzare la configurazione dell'applicazione Web o del servizio usando metadati WS-Federation, perché la chiave pubblica dello spazio dei nomi viene pubblicata nei metadati WS-Federation per lo spazio dei nomi Controllo di accesso. L'URL del documento metadati WS-Federation viene visualizzato nella pagina Integrazione applicazione del portale di gestione ACS.
Usa certificato dedicato: se si seleziona questa opzione, ACS usa un certificato specifico dell'applicazione per firmare i token SAML 1.1 e SAML 2.0 per l'applicazione relying party. Il certificato non viene usato per altre applicazioni relying party. Dopo la selezione di questa opzione, cercare un certificato X.509 con chiave privata (file con estensione pfx), quindi immettere la password per il file con estensione pfx.
Nota
Token JWT. Quando si configura un'applicazione relying party per l'uso del certificato X.509 per lo spazio dei nomi Controllo di accesso per firmare i token JWT per un'applicazione relying party, i collegamenti al certificato dello spazio dei nomi Controllo di accesso e al Controllo di accesso La chiave dello spazio dei nomi viene visualizzata nella pagina per l'applicazione relying party nel portale di gestione ACS. Tuttavia, ACS usa solo il certificato dello spazio dei nomi per firmare i token per l'applicazione relying party.
Spazi dei nomi gestiti. Quando si aggiunge un'applicazione relying party a uno spazio dei nomi gestito, ad esempio del Bus di servizio, non immettere certificati o chiavi (dedicati) specifici dell'applicazione. Selezionare, invece, le opzioni che consentono ad ACS di usare i certificati e le chiavi configurate per tutte le applicazioni nello spazio dei nomi gestito. Per altre informazioni, vedere Spazi dei nomi gestitiPer altre informazioni su certificati e chiavi condivisi e dedicati, vedere Certificati e chiavi.
Opzioni relative alle chiavi simmetriche
Come procedura consigliata per la sicurezza, quando si usano chiavi simmetriche, creare una chiave dedicata per ogni applicazione relying party, anziché usare la chiave simmetrica condivisa per lo spazio dei nomi Controllo di accesso. Se si immette o si genera una chiave dedicata, ACS usa una chiave dedicata per firmare i token per l'applicazione relying party, purché la chiave dedicata sia valida. Tuttavia, se la chiave dedicata scade e non viene sostituita, ACS usa la chiave dello spazio dei nomi condiviso per firmare i token per l'applicazione relying party.
Se si sceglie di usare la chiave simmetrica condivisa, copiare i valori per la chiave Spazio dei nomi del servizio dalla pagina Certificati e chiavi e incollarli nei campi della sezione Firma di token della pagina Applicazioni relying party.
Le opzioni seguenti sono disponibili per i token firmati con chiavi simmetriche.
Chiave di firma del token: immettere una chiave simmetrica a 256 bit oppure fare clic su Genera per generare una chiave simmetrica a 256 bit.
Data di validità: specifica la data di inizio dell'intervallo di date di validità della chiave simmetrica. A partire da questa data, ACS usa la chiave simmetrica per firmare i token per l'applicazione relying party. Il valore predefinito ACS è la data corrente.
Data di scadenza: specifica la data di fine dell'intervallo di date di validità della chiave simmetrica. Da questa data in avanti, ACS non usa la chiave simmetrica per firmare i token per l'applicazione relying party. Non è previsto alcun valore predefinito. Come procedura consigliata per la sicurezza, è opportuno sostituire le chiavi simmetriche ogni anno oppure ogni due anni, in base ai requisiti dell'applicazione.
Crittografia dei token
L'opzione del certificato relativa alla crittografia dei token specifica il certificato X.509 (file con estensione cer) usato per crittografare i token per l'applicazione relying party. In ACS è possibile crittografare solo i token SAML 2.0 o SAML 1.1. ACS non supporta la crittografia dei token SWT o JWT.
Specificare i certificati per la crittografia dei token nella sezione Certificati e chiavi del portale ACS. Quando si fa clic sul collegamento Fare clic qui nella sezione Criterio di crittografia token della pagina relativa all'applicazione relying party, verrà aperta la pagina Aggiungi certificato di crittografia di token di Certificati e chiavi. Usare questa pagina per specificare un file di certificato.
Per altre informazioni, vedere Criteri di crittografia dei token. Per altre informazioni su come ottenere e aggiungere certificati di crittografia, vedere Certificati e chiavi.