Single sign-out
Updated: June 19, 2015
Applies To: Azure
Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) now includes an optional single-sign-out capability to complement single sign-on. The result is a complete and consistent sign-on and sign-out experience for users of web-based applications that are integrated with ACS.
When an end user signs out of a relying party application that supports single sign-on, ACS can automatically sign the user out of the identity provider site and sign them out of all other applications that they signed onto by using that identity provider. Similarly, if the customer signs out of the identity provider web site, ACS can automatically sign the customer out of applications that they signed onto by using the identity provider.
This topic explains how single sign-out works and how to implement single sign-out for your relying party application. Be sure to review the sample code for implementing federated single sign-out in an ASP.NET MVC 4 application at Code Sample: ASP.NET MVC 4 with Federated Sign-outt.
System Requirements
To implement single sign-out, the following tools and services are required.
Azure subscription
Visual Studio 2012
About Single Sign-Out
In each browser session, a customer can select a federated identity provider to sign onto a relying party application. With single sign-out, when the user signs out of the identity provider or the relying party application, the customer is automatically signed out of all relying party applications that they signed on to by using the same identity provider.
For example, the customer uses a Microsoft account (Windows Live ID) to sign onto three ACS-integrated relying party applications. When the customer signs out of any one of the applications, they are automatically signed out of their Microsoft account and signed out of the other two applications.
Full single sign-out support is available for custom WS-Federation and ADFS identity providers. Limited single sign-out support is available for the Facebook, Google, Microsoft account, and Yahoo! identity providers. These identity providers cannot initiate single sign-out. However, when a relying party application initiates single sign-out, the customer is signed out of these identity providers, and associated relying party applications that they signed on to by using that identity provider.
How Single Sign-Out Works
Single sign-out can be initiated by the identity provider or the relying party application. In this section, we review each of these sign-out processes and explain how you can enable single sign out for your relying party application.
Relying Party Application Initiates Sign-Out
To initiate single sign-out when a user signs out of your relying party application, send a URL with the following parameters to the ACS WS-Federation endpoint.
wa: Set to wsignout1.0
wreply: Set the value to the URL of the logout page, that is, the page where the user is redirected when sign out is complete. This value should be the part of the RP domain name, such as "https://RP.com/"
wtrealm: Set to the value of the Realm property of the relying party application in the ACS Management Portal.
The following is a sample URL for single sign-out.
https://<YourNamespace>.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wtrealm=<YourAppRealm>&wreply=<YourAppRealmLogoutPage>
For example:
https://Fabrikam.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wtrealm=" https://www.fabrikam.com/" &wreply= https://www.fabrikam.com/logout
For sample code that implements relying party-initiated single sign-out, see Code Sample: ASP.NET MVC 4 with Federated Sign-out. This sample includes code in LogoutController.cs that gets the wreply and wrealm values and creates an instance of the SignOutRequestMessage class.
When ACS receives the sign-out URL, ACS ends the customer's session with the identity provider by sending a wsignout1.0 request. Then, ACS sends wsignoutcleanup1.0 messages to other relying party applications that the user signed onto by using the identity provider.
Identity Provider Initiates Sign-Out
Identity provider-initiated sign-out is supported only for custom WS-Federation and ADFS identity providers. It cannot be supported for Microsoft Account (Windows Live ID), Google, Yahoo!, and Facebook identity providers because these identity providers do not notify ACS or the relying party application when the user signs out.
When the user signs out of a WS-Federation or ADFS identity provider, the identity provider sends ACS a wsignoutcleanup1.0 sign-out clean up request message with the following format: https://<YourNamespace>.accesscontrol.windows.net/v2/wsfederation?wa=wsignoutcleanup1.0
When ACS receives a wsignoutcleanup1.0 message, it verifies that the request originated from the same endpoint as the sign-in request by validating the referrer in the HTTP header of the message: <Referrer>: https://CustomIDP where the value of <Referrer> is the value of referrer in the sign-in URL in the ACSSignOut cookie.
Then, ACS sends a wsignoutcleanup1.0 message to all relying party applications in the current user's client browser session that are associated with the identity provider. The process is similar to the process that is described in the “Relying Party Application Initiates Sign-Out” section. The identity provider can redirect the browser to a sign-out page that it controls to complete the sign-out process.
Single Sign-out Process
This section describes each step in the single sign-out process. Because ACS handles the details for you, you do not need to understand this process. However, it might be useful in customization or debugging.
Single Sign-Out Step-by-Step
When ACS receives a signout1.0 request at its WS-Federation endpoint, ACS looks up the identity provider of the sign-out request initiator in the ACSSignOut cookie.
ACS uses the following matching rules to identify the identity provider.
If the wtrealm parameter is specified in the sign-out request, ACS searches for the wtrealm value in the list of relying parties for each identity provider.
If wtrealm is not specified and there is only one identity provider entry in the ACSSignOut cookie, ACS uses the identity provider in the ACSSignOut cookie.
Otherwise, ACS displays an error page indicating that the attempt sign out failed because the wtrealm parameter is missing.
ACS sends a signout1.0 message to the identity provider by presenting a page with an inline frame (<iframe>) element. ACS also adds <iframe> elements that contains the SignOutCleanup1.0 message to the pages of all active WS-Federation relying parties other than the initiating party and ACS removes the relying parties from the ACSSignOut cookie.
The page that displays the relying party sign-out status also contains JavaScript that runs for a specified time and then redirects the browser. If a wreply parameter was specified in the ACSSignOut cookie, the JavaScript redirect to the address indicated by the wreply value to complete the sign-out. Otherwise, the JavaScript redirects to the Return URL of the relying party, as specified in the ACS Management Portal.
ACSSignOut Cookie
ACS uses a session cookie named ACSSignOut to record the identity provider that authenticated the user to the application. You can view the cookie in session traces. The session cookie has the following name format: ACSSignOut.<YourACSNamespace>.
The ACSSignOut cookie identifies the relying party application and the identity provider that authenticated the user. ACS uses the cookie during single sign-out to ensure that correct identity provider is signed out and that the user is signed out of other relying party applications that they signed on to by using the identity provider.
Limitations of Single Sign-Out
When using single sign-out, be aware of the following limitations.
Only custom WS-Federation identity providers and ADFS identity providers can initiate single sign-out. Social identity providers, such as Yahoo, Google, Microsoft Account (Windows Live ID) and Facebook, do not notify ACS or the relying party application when the customer signs out of the identity provider website. Therefore, users of relying party applications that use these identity provider are not automatically signed out when the sign-out originates at the identity provider site.
Single sign-out might not be effective in all environments. When ACS receives a single sign-out message from a relying party application, it sends a wsignout1.0 request to the identity provider and a wsignoutcleanup1.0 message to each of the other relying party applications. When ACS receives a wsignoutcleanup1.0 request message from an identify provider, it sends a wsignoutcleanup1.0 message to each of the relying party applications. However, ACS cannot guarantee that the identify provider or relying party applications will respond appropriately by signing the user out.
When users sign out of the Google identity provider in Internet Explorer, the browser displays an "Only secure content is displayed" prompt. To complete sign-out, users must click "Show all content". When sign-out is complete, the browser is redirected to the URL specified by the value of the wreply parameter.
Internet Explorer 9, and later versions of Internet Explorer, displays the secure content notice when it encounters non-secured content on a secured page, such as images or scripts that originate from a non-secured server. In this case, it is reacting to secure (HTTPS/SSL) ACS content and non-secure (HTTP) content from the identity provider. ACS cannot change or suppress this behavior.
Users can suppress the notice, as described in "Only secure content is displayed” notification in Internet Explorer 9 or later. However, because this setting applies to all websites and might make the user's computer vulnerable to malicious content, the default setting, which blocks non-secure (HTTP) content, is recommended.
To help end users to initiate single sign-out, the sign-out page of relying party application should instruct users to close the browser or explicitly sign-out of other relying party applications and the identity provider website. Closing a browser tab, window, or page is not sufficient. If the computer is shared or in a public place, such as a kiosk computer, the users should clear the browser history before closing the browser.
See Also
Concepts
Code Sample: ASP.NET MVC 4 with Federated Sign-out