Add "Front-Channel Logout" support to Gloo

[htech7x]

Gloo Edge Product

Enterprise

Gloo Edge Version

1.16.8

Context

Gloo Edge currently does not support OIDC Front Channel Logout, a specification that in an SSO environment that includes multiple applications, allows the user to logout of all these applications by simply logging out of their current SSO session.

In the past, we've advised users to use the afterLogoutUrl as a workaround, by implementing the logout functionality of all the applications in an iFrame in that afterLogoutUrl. This is very much a "poor man's solution" to a problem for which there is a solution defined in the OIDC specification.

Requirements

An implementation of the OIDC Front Channel Logout specification.

Job Stories

TODO

Additional Context

Currently we advise users to use the "afterLogoutUrl" as a workaround since Gloo doesn't support front-channel logout. Example of using "afterLogoutUrl":

apiVersion: enterprise.gloo.solo.io/v1
kind: AuthConfig
metadata:
  name: oauth
  namespace: gloo-system
spec:
  configs:
  - oauth2:
      oidcAuthorizationCode:
        afterLogoutUrl: https://httpbin.solo.io/prompt
        appUrl: https://httpbin.solo.io
        callbackPath: /callback
        clientId: b036d586-983f-4568-a882-5a9f499aa60e
        clientSecretRef:
          name: oauth
          namespace: gloo-system
        issuerUrl: http://ae6ce2927b9b445a6a84f7cf3a0b5878-122919987.us-east-2.elb.amazonaws.com:8080/auth/realms/master/
        logoutPath: /logout
        scopes:
        - email
        session:
          failOnFetchFailure: true
          redis:
            cookieName: keycloak-session
            options:
              host: redis.gloo-system.svc.cluster.local:6379

┆Issue is synchronized with this Asana task by Unito

[soloio-bot]

Zendesk ticket #3739 has been linked to this issue.

[DuncanDoyle]

Seems like the main problem is that when we hit the Gloo logoutPath, Gloo does a direct call to the OAuth/OIDC end_session_endpoint directly from the proxy, and does not handle the response, and simply does a redirect to the appUrl or afterLogoutUrl (if configured).

This seems to prevent our users to implement Front Channel Logout, as the idea behind that flow is that the "Relying Party" (RP) or Application on logout redirects the browser (agent) to the OP (OpenID Provider) logout path, and then the OpenID provider responds loading a set of iframes under OpenID provider’s domain, which will send logout requests to other client applications which do have active login sessions on the same browser.

So, we could solve this by making the action that Gloo executes when the logoutPath hits configurable. Something like a logoutStrategty with support for FrontChannelLogout (and maybe later BackChannelLogout) would solve this.

[nrjpoddar]

@sam-heilbron to look at this issue for scope/estimation.