Single Sign-Out

Aggiornamento: 19 giugno 2015

Si applica a: Azure

Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS) include ora una funzionalità di single sign-out facoltativa per integrare l'accesso Single Sign-On. Il risultato è un'esperienza di accesso e disconnessa completa e coerente per gli utenti di applicazioni basate sul Web integrate con ACS.

Quando un utente finale esce da un'applicazione relying party che supporta Single Sign-On, ACS può disconnettere automaticamente tale utente dal sito del provider di identità e da tutte le altre applicazioni a cui ha eseguito l'accesso usando il provider di identità stesso. Analogamente, se il cliente si disconnette dal sito Web del provider di identità, ACS può disconnettere automaticamente tale cliente dalle applicazioni a cui ha eseguito l'accesso usando il provider di identità stesso.

Questo argomento descrive il funzionamento di Single Sign-Out e fornisce le istruzioni per l'implementazione di Single Sign-Out per l'applicazione relying party dell'utente. Assicurarsi di esaminare il codice di esempio per l'implementazione dell'accesso Single Sign-Out federato in un'applicazione ASP.NET MVC 4 in Esempio di codice: ASP.NET MVC 4 con Federated Sign-outt.

Requisiti di sistema

Per implementare Single Sign-Out sono richiesti gli strumenti e i servizi indicati di seguito.

  • Sottoscrizione di Azure

  • Visual Studio 2012

Informazioni su Single Sign-Out

In ogni sessione del browser un cliente può selezionare un provider di identità federato per eseguire l'accesso a un'applicazione relying party. Con Single Sign-Out, quando l'utente si disconnette dal provider di identità o dall'applicazione relying party, viene disconnesso automaticamente da tutte le applicazioni relying party a cui aveva eseguito l'accesso usando lo stesso provider di identità.

Si supponga, ad esempio, che il cliente usi un account Microsoft (Windows Live ID) per eseguire l'accesso a tre applicazioni relying party integrate con ACS. Quando il cliente si disconnette da una delle applicazioni, viene automaticamente disconnesso dall'account Microsoft e dalle altre due applicazioni.

Il supporto completo per Single Sign-Out è disponibile per provider di identità WS-Federation personalizzati e per provider di identità ADFS. È disponibile un supporto limitato per l'accesso Single Sign-Out per Facebook, Google, account Microsoft e Yahoo! provider di identità. Questi provider di identità non possono avviare l'accesso Single Sign-Out. Tuttavia, quando un'applicazione relying party avvia l'accesso Single Sign-Out, il cliente viene disconnesso da questi provider di identità e le applicazioni relying party associate a cui hanno eseguito l'accesso usando tale provider di identità.

Funzionamento di Single Sign-Out

Single Sign-Out può essere avviato dal provider di identità o dall'applicazione relying party. In questa sezione vengono esaminati tali processi di disconnessione e viene spiegato come abilitare Single Sign-Out per l'applicazione relying party.

Single Sign-Out avviato dall'applicazione relying party

Per avviare Single Sign-Out quando un utente si disconnette dall'applicazione relying party, inviare all'endpoint WS-Federation di ACS un URL con i seguenti parametri.

  • wa: impostare su wsignout1.0

  • wreply: impostare il valore sull'URL della pagina di disconnessione, ovvero la pagina in cui l'utente viene reindirizzato al termine della disconnessione. Questo valore deve essere la parte del nome di dominio RP, ad esempio "https://RP.com/"

  • wtrealm: impostare sul valore della proprietà Realm dell'applicazione relying party nel portale di gestione ACS.

Di seguito è riportato un URL di esempio per Single Sign-Out.

https://<YourNamespace>.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wtrealm=<YourAppRealm>&wreply=<YourAppRealmLogoutPage>

Ad esempio:

https://Fabrikam.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wtrealm=" https://www.fabrikam.com/" &wreply= https://www.fabrikam.com/logout

Per il codice di esempio che implementa l'accesso Single Sign-Out avviato dalla relying party, vedere Esempio di codice: ASP.NET MVC 4 con disconnesso federato. Questo esempio include codice in LogoutController.cs che ottiene i valori wreply e wrealm e crea un'istanza della classe SignOutRequestMessage.

Quando ACS riceve l'URL di disconnessione, ACS termina la sessione del cliente con il provider di identità inviando una richiesta wsignout1.0 . ACS invia quindi messaggi wsignoutcleanup1.0 ad altre applicazioni relying party a cui l'utente ha eseguito l'accesso usando il provider di identità.

Single Sign-Out avviato dal provider di identità

Single Sign-Out avviato dal provider di identità è supportato soltanto per provider di identità WS-Federation personalizzati e per provider di identità ADFS. Non è supportato per provider di identità di account Microsoft (Windows Live ID), Google, Yahoo! e Facebook perché tali provider non notificano ad ACS o all'applicazione relying party che l'utente si è disconnesso.

Quando l'utente si disconnette da un provider di identità WS-Federation o ADFS, il provider di identità invia a ACS un messaggio di pulizia della richiesta di disconnessione wsignoutcleanup1.0 con il formato seguente: https://<YourNamespace>.accesscontrol.windows.net/v2/wsfederation?wa=wsignoutcleanup1.0

Quando ACS riceve un messaggio wsignoutcleanup1.0 , verifica che la richiesta abbia avuto origine dallo stesso endpoint della richiesta di accesso convalidando il referrer nell'intestazione HTTP del messaggio: <Referrer>: https://CustomIDP dove il valore di Referrer è il valore di <referrer> nell'URL di accesso nel cookie ACSSignOut .

ACS invia quindi un messaggio wsignoutcleanup1.0 a tutte le applicazioni relying party nella sessione del browser client dell'utente corrente associata al provider di identità. Questo processo è simile a quello descritto nella sezione “Single Sign-Out avviato dall'applicazione relying party”. Per completare il processo di disconnessione, il provider di identità può reindirizzare il browser a una pagina di disconnessione su cui ha il controllo.

Processo Single Sign-Out

Questa sezione descrive i diversi passaggi del processo Single Sign-Out. Poiché ACS gestisce automaticamente i dettagli, non è necessario comprendere appieno questo processo. La comprensione dei dettagli, tuttavia, può rivelarsi utile per le operazioni di personalizzazione o debugging.

Single Sign-Out - Procedura dettagliata

  1. Quando ACS riceve una richiesta signout1.0 nel relativo endpoint WS-Federation, ACS cerca il provider di identità dell'iniziatore della richiesta di disconnessione nel cookie ACSSignOut.

    Per individuare il provider di identità, ACS usa le regole di associazione riportate di seguito.

    • Se il parametro wtrealm viene specificato nella richiesta di disconnessione, ACS cerca il valore wtrealm nell'elenco delle relying party per ogni provider di identità.

    • Se wtrealm non è specificato e nel cookie ACSSignOut è presente una sola voce del provider di identità, ACS usa il provider di identità nel cookie ACSSignOut.

    • In caso contrario, ACS visualizza una pagina di errore che indica che il tentativo di disconnesso non è riuscito perché il parametro wtrealm non è presente.

  2. ACS invia un messaggio signout1.0 al provider di identità presentando una pagina con un elemento frame inline (<iframe>). ACS aggiunge <anche elementi iframe> che contengono il messaggio SignOutCleanup1.0 alle pagine di tutte le relying party attive WS-Federation diverse dall'entità di avvio e ACS rimuove le relying party dal cookie ACSSignOut .

  3. La pagina che visualizza lo stato di disconnessione della relying party contiene anche il codice JavaScript eseguito a un'ora specifica e che reindirizza il browser. Se nel cookie ACSSignOut è stato specificato un parametro wreply , il reindirizzamento JavaScript all'indirizzo indicato dal valore wreply per completare la disconnessione. In caso contrario, JavaScript reindirizza all'URL restituito della relying party, come specificato nel portale di gestione ACS.

ACS usa un cookie di sessione denominato ACSSignOut per registrare il provider di identità che ha autenticato l'utente nell'applicazione. È possibile visualizzare il cookie nelle tracce della sessione. Il cookie di sessione ha il formato del nome seguente: ACSSignOut.<YourACSNamespace>.

Il cookie ACSSignOut identifica l'applicazione relying party e il provider di identità che ha autenticato l'utente. Durante il processo Single Sign-Out, ACS usa il cookie per garantire che venga disconnesso il provider di identità corretto e che l'utente venga disconnesso dalle applicazioni relying party a cui ha eseguito l'accesso usando il provider di identità.

Limitazioni di Single Sign-Out

Quando si usa Single Sign-Out, tenere conto delle seguenti limitazioni.

  • Solo i provider di identità di WS-Federation personalizzati e i provider di identità ADFS possono avviare l'accesso Single Sign-Out. I provider di identità social, ad esempio Yahoo, Google, Account Microsoft (Windows Live ID) e Facebook, non notificano a ACS o all'applicazione relying party quando il cliente si disconnette dal sito Web del provider di identità. Di conseguenza, gli utenti di applicazioni relying party che usano questi provider di identità non vengono automaticamente disconnessi quando il processo di disconnessione ha origine nel sito del provider di identità.

  • È possibile che Single Sign-Out non funzioni correttamente in tutti gli ambienti. Quando ACS riceve un messaggio single sign-out da un'applicazione relying party, invia una richiesta wsignout1.0 al provider di identità e un messaggio wsignoutcleanup1.0 a ognuna delle altre applicazioni relying party. Quando ACS riceve un messaggio di richiesta wsignoutcleanup1.0 da un provider di identificazione, invia un messaggio wsignoutcleanup1.0 a ogni applicazione relying party. ACS, tuttavia, non è in grado di garantire che il provider di identità o l'applicazione relying party rispondano in modo appropriato disconnettendo l'utente.

  • Quando l'utente si disconnette dal provider di identità Google in Internet Explorer, il browser visualizza il prompt "Viene visualizzato solo il contenuto sicuro". Per completare la disconnessione, l'utente deve fare clic su "Mostra tutto il contenuto". Al termine della disconnessione, il browser viene reindirizzato all'URL specificato dal valore del parametro wreply .

    Internet Explorer 9 (e versioni successive) visualizza l'avviso relativo al contenuto sicuro quando rileva la presenza di contenuto non sicuro su una pagina protetta, ad esempio immagini o script provenienti da un server non sicuro. In questo caso, Internet Explorer reagisce allo stesso modo quando rileva contenuto ACS sicuro (HTTPS/SSL) e non sicuro (HTTP) proveniente dal provider di identità. ACS non è il grado di modificare o eliminare questo comportamento.

    Gli utenti possono eliminare l'avviso, come descritto in "Viene visualizzato solo contenuto sicuro" notifica in Internet Explorer 9 o versione successiva. Tuttavia, poiché questa impostazione si applica a tutti i siti Web e potrebbe rendere vulnerabile il computer dell'utente esponendolo a contenuto dannoso, si consiglia di mantenere l'impostazione predefinita che blocca il contenuto non sicuro (HTTP).

Per consentire agli utenti finali di avviare Single Sign-Out, la pagina di disconnessione dell'applicazione relying party deve indicare agli utenti di chiudere il browser o di disconnettersi in modo esplicito dalle altre applicazioni relying party e dal sito Web del provider di identità. La chiusura della scheda, della finestra o della pagina del browser non è sufficiente. Se il computer è condiviso o si trova in un luogo pubblico, come nel caso del computer di un chiosco multimediale, prima di chiudere il browser gli utenti devono cancellarne la cronologia.

Vedere anche

Concetti

Esempio di codice: ASP.NET MVC 4 con disconnesso federato

Risorse aggiuntive

Autenticazione passiva per ASP.NET con WIF