You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order run sessions in their own subdomains. We need to change how access to the sessions is controlled.
The biggest problem is that we currently use the oauth2 proxy container in every jupyter server to control access. Because of this we would have to register different callbacks in keycloak for every session. This is not feasible.
So we would like to address the above problem with the following:
remove the oauth2 proxy from every session
add a traefik instance in every session that handles the ingress
when the session is created traefik is setup to inject the user's keycloak ID in every incoming request
the traefik container uses the forwardAuth middleware in traefik to check that the users ID that the session was created with matches the signed in users id who is trying to access the session
The forwardAuth middleware forwards the request to an external service to make a decisions if the request should succeed or not. If the external service responds with 2XX the request goes through otherwise it does not. So the gateway can have an endpoint where it does this check.
The text was updated successfully, but these errors were encountered:
p.s. There may be a really quick and dirty way to achieve something similar here. But we should estimate what is proposed up here instead. I will try to test this out ahead of time.
In order run sessions in their own subdomains. We need to change how access to the sessions is controlled.
The biggest problem is that we currently use the oauth2 proxy container in every jupyter server to control access. Because of this we would have to register different callbacks in keycloak for every session. This is not feasible.
So we would like to address the above problem with the following:
The forwardAuth middleware forwards the request to an external service to make a decisions if the request should succeed or not. If the external service responds with 2XX the request goes through otherwise it does not. So the gateway can have an endpoint where it does this check.
The text was updated successfully, but these errors were encountered: