Federated Signout Requests - Automatic iframe rendering

[parkinsona]

I have a question regarding External Logout notification (https://docs.duendesoftware.com/identityserver/ui/logout/external-notification/)

Fortunately IdentityServer already contains this code. When requests come into IdentityServer and invoke the handlers for external authentication providers, IdentityServer detects if these are federated signout requests and if they are it will automatically render the same <iframe> as described here for logout.

According to that documentation, it sounds like I don't need to do anything for IdentityServer to automatically render the necessary iframes for logout. However, this is the behavoiur I'm getting.

Scenario 1 - user logs into site A and B, both authenticated using IdentityServer (with the local provider). Site A has frontChannel logout uri configured. When Site B is logged out, IdentityServer is logged out, as is site A. This works as expected.
Scenario 2 - user logs into site A and B, both authenticated using IdentityServer (with an external identity provider). Site A has frontChannel logout uri configured. When Site B is logged out, IdentityServer is logged out, as is site A. This works as expected.
Scenario 3 - user logs into site A and B, both authenticated using IdentityServer (with external identity provider). Site A has frontChannel logout uri configured. The user logs out of their external identity provider. It will logout of identity server, but not out of Site A or B.

I do not use the Duende implementation of dynamic providers.
We have a custom SchemeProviderLoader to add in our identity Providers from our store.

  private async Task<bool> TryAddOpenIdConnectSchemeAsync(OpenIdConnectProvider provider)
     {
         provider.Options.SignInScheme = IdentityConstants.ExternalScheme;
         provider.Options.SignOutScheme = Duende.IdentityServer.IdentityServerConstants.SignoutScheme;

         provider.Options.CallbackPath = new PathString($"/signin-oidc/{provider.IdpName}");
         provider.Options.SignedOutCallbackPath = new PathString($"/signout-callback-oidc/{provider.IdpName}");
         provider.Options.RemoteSignOutPath = new PathString($"/signout-oidc/{provider.IdpName}");
         provider.Options.Scope.Add("email");
         provider.Options.SaveTokens = true; // required to persist the id_token for the external provider logout.
         provider.Options.Events = new OpenIdConnectEvents()
         {
             OnRemoteSignOut = async context =>
             {                    
                 // when we receive a front channel logout from the OIDC provider. We need to somehow hit the end session endpoint of identity.
                 return Task.CompletedTask;
             },
             OnRedirectToIdentityProvider = context =>
             {
                 context.ProtocolMessage.LoginHint = context.Properties.Items["login_hint"];
                 return Task.CompletedTask;
             },
             OnTokenValidated = context =>
             {
                 return Task.CompletedTask;
             },
             OnRedirectToIdentityProviderForSignOut = async context =>
             {
                 // set the idtoken hint so it can allow signout on the external provider.
                 context.ProtocolMessage.IdTokenHint = await context.HttpContext.GetTokenAsync(OpenIdConnectResponseType.IdToken);
             },
         };

         return await TryAddSchemeAsync<OpenIdConnectHandler, OpenIdConnectOptions>(provider.IdpName, provider.IdpCaption, provider.Options, oidcPostConfigureOptions, oidcOptionsCache);
     }
     
             private async Task<bool> TryAddSchemeAsync<TAuthenticationHandler, TOptions>(string name, string displayName, TOptions options, IPostConfigureOptions<TOptions> postConfigureOptions, IOptionsMonitorCache<TOptions> optionsMonitorCache)

         where TAuthenticationHandler : IAuthenticationHandler
         where TOptions : AuthenticationSchemeOptions
     {
         if (await schemeProvider.GetSchemeAsync(name) == null)
         {
             // Add the scheme.
             schemeProvider.AddScheme(new AuthenticationScheme(name, displayName, typeof(TAuthenticationHandler)));
             postConfigureOptions.PostConfigure(name, options);
             return optionsMonitorCache.TryAdd(name, options);
         }

         return false;
     }

Identityserver does receive the federated signout request, as I can debug and see that OnRemoteSignout is being hit.

According to the doco, it sounds like you don't have to implement a custom OnRemoteSignout, but that doesn't seem to be the case unless perhaps you're using Duende's Dynamic Providers?

I am looking at creating the necessary iframes myself in OnRemoteSignout, but not entirely sure of the most appropriate way to go about this.

[RolandGuijt]

Just to rule this out: when a signout from the external IdP occurs, is IdentityServer's logout page (which contains the iFrame) rendered?

[parkinsona]

Hi Roland,
Thanks for the reply.

This is what is shown in the browser:

And these are the iframes produced on that signout page:

<div>       
        <iframe src="https://outlook.office365.com/mail/logoutframe.html?sid=004e4ef9-2551-c0c9-475b-1d365ef065d3" style="display: none"></iframe>
        <iframe src="https://localhost:44386/core/signout-oidc/testOIDC?sid=004e4ef9-2551-c0c9-475b-1d365ef065d3" style="display: none"></iframe>
        </div>

So it does include the iframe to IdentityServer's signout endpoint.
But that endpoint doesn't then output the iframes for the relying parties.

I have found I can add html to the iframe manually in OnRemoteSignout, doing something like the below. But, the documentation makes it sound like this should happen automatically. I don't mind writing something here to implement it, but I'm not sure the correct way to do it (as I've also seen recommendations to redirect to the endsession endpoint from OnRemoteSignout)

OnRemoteSignOut = async context =>
{
    var html = "<html><body>";
    html += "<p>You are now signed out.</p></body></html>";

    context.Response.ContentType = "text/html";
    await context.Response.WriteAsync(html);
    context.HandleResponse();
}

[AndersAbel]

Thanks for the additional information.

The front-channel logout using hidden iframes relies on both IdentityServer and all client applications to be able to interact with any cookies on each host. For this to work, all cookies must be set to SameSite=None when a cross-site upstream provider is used. As Entra Id is hosted on it's own domain, it's always cross-site to any of your applications.

The IdentityServer session cookie is SameSite=None by default, did you change that to SameSite=Lax or SameSite=Strict? The client cookies are SameSite=Lax by default in the Microsoft OpenIdConnect handler, you need to change them to SameSite=None in the settings. If you check the browser dev tools, you should be able to see if the cookies are allowed or blocked on the relevant requests.

Finally, if you are running Safari, none of this will probably work, as they are blocking cookies in third party context even if the cookies are marked as SameSite=None.

[parkinsona]

Thanks Anders.
The cookies in the clients are still set to the default of SameSite=Lax.

You mentioned that this won't work in safari. Is this blocking of third party going to be enforced in other browsers in the future. I think I read that it was going to start happening in chrome as well in the future.

We're just trying to work out if it's worth making the change, if browsers are going to start blocking it anyway.
In other words, is front-channel logout, on the way out?

Back channel is probably the better route, although a bit more work, as we'd need to implement some form of session store, as we're in a load balanced environment.

[RolandGuijt]

Yes, front channel logout is definitely something that will become harder and harder in the future as browsers get more strict with cookie handling. Don't know if you're aware, but IdentityServer has server-side session store support built in.

[parkinsona]

Thanks Roland.

Thanks for reminding me of the identity server side session store, I had looked at that in the past.
The issue is more the relying parties being load balanced. I found in my initial testing of back channel logout, the relying party would require server session storage.

Thanks again for your help.