Add "Front-Channel Logout" support to Gloo
htech7x opened this issue · comments
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
Zendesk ticket #3739 has been linked to this issue.
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.