Skip to content

Federated sign-out and IdentityServer3

February 9, 2016

The federation gateway pattern

Consider a scenario where you are building an application that requires the user to login from a variety of identity providers (IdPs). It is possible to implement the logic necessary to juggle the different IdPs from within a single application. But once you have more than one application with this same requirement it is undesirable to repeatedly re-implement this logic in each application.

This is where the “federation gateway” architectural pattern is commonly used. This involves using a token service in-between you applications and the IdPs being used. The logic of juggling the different IdPs is then consolidated in the gateway, and your applications are abstracted from these details.

IdentityServer3 can be (and frequently is) used in this capacity.

Below is a picture of the federation gateway pattern:

a.png

Federated sign-out

It’s not inconceivable that an IdP that’s being used has other applications relying upon it for authentication beyond your federation gateway. For example:

b.png

So what happens with a user of “Not Your App” logs out? Well, single sign-out can be done in many ways. Regardless of the approach, normally the user is redirected to the IdP to sign-out (“SalesForce” in the picture above). At this point, it would be quite useful for your gateway to know that this has occurred. Once your gateway knows the user has signed out of the IdP, the gateway can sign the user out, and then notify your applications to sign the user out as well.

This is all possible in IdentityServer3 as of build 2.2 released in November 2015, assuming the IdP being used supports a “front-channel” approach for single sign-out. Recall that a “front-channel” approach to sign-out creates an <iframe> to each of the client applications in the context of the user’s browser session, thus allowing the application to do any session related cleanup (such as revoking cookies).

To achieve this it is necessary for you to build an endpoint within the gateway that can act as the “cleanup endpoint” (which will be the target of the IdP’s <iframe>). This is something you must do manually, since you might be using different protocols to authenticate to the IdP (e.g. OIDC or WS-Fed). This endpoint would need to run within IdentityServer’s pipeline, meaning the URL must be one such that the IdentityServer middleware is allowed to execute. From that endpoint you would then use an OWIN environment extension API called ProcessFederatedSignoutAsync that we provide. This API performs the federated sign-out.

The “cleanup endpoint” might look some like this:

public void Configuration(this IAppBuilder app)
{
   app.Map("/core", coreApp =>
   {
      var factory = new IdentityServerServiceFactory();

      // ...

      coreApp.UseIdentityServer(idsrvOptions);
      
      coreApp.Map("/signoutcleanup", cleanup =>
      {
         cleanup.Run(async ctx =>
         {
            await ctx.Environment.ProcessFederatedSignoutAsync();
         });
      });
   });
}

Depending on the protocol used with the IdP you might need more logic in here, but the above code is all that’s needed to handle signing out from IdentityServer and to the applications using IdentityServer for authentication (assuming the applications themselves participate in single sign-out).

You can read more about the federated sign-out support in our docs.

 

2 Comments leave one →
  1. March 1, 2016 3:54 am

    Hi,

    I’m trying to implement a federated sign out and I’m experiencing an issue which I’m not sure if you’ve come across before?

    Identity Server is hosted on identity.mydomain.com

    Our single sign on solution is hosted on myaccount.mydomain.com

    If on the sign-out page of our single sign on solution I embed the iframe to identity.mydomain.com/signoutcleanup and try and navigate to this page in chrome I’m getting the following error:

    Refused to display ‘https://identity.mydomain.com/signoutcleanup’ in a frame because it set ‘X-Frame-Options’ to ‘SAMEORIGIN’.

    I understand WHY this is happening (as X-Frame-Options is set to SAMEORIGIN by IdentiyServer) but I’m struggling to get it to work. I should point out they’re on the same protocol and same port – it’s purely the subdomain that’s different.

    I’ve attempted to set document.domain on both the sign out page and the signoutcleanup page as per these docs https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

    However that’s not been successful. Any hints or pointers you might be able to provide would be great. I realise I could disable X-Frame-Options in IdentityServer but obviously I’d rather not do that!

    Cheers,
    Richard

  2. catdevnull permalink
    March 1, 2016 6:35 am

    Hi,

    Following on from my previous comment this can be ignored – the issue was caused by X-Frame-Options being set by IIS which was overriding Identity Server’s correct use of the header.

    Removed the IIS header and the problems have now resolved.

    Pro Tip: Never trust your infrastructure configuration when someone else set it up.

    Thanks,
    Richard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: