Federated sign-out and IdentityServer3

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:

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:

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.