Re: [keycloak-user] Keycloak Gatekeeper: Support Relative/Internal URLs for Airgapped Environments

Hi all, I am a contributor to the Kubeflow project, which is a machine learning platform built on top of Kubernetes. Recently, we (Arrikto) implemented a reference architecture for OIDC Authentication in Kubeflow. More details can be found in this article: https://journal.arrikto.com/kubeflow-authentication-with-istio-dex-5eafdf... After 3 months of testing this setup with users, we gathered feedback from users operating in onprem, airgapped environments which lead to the following use case: We want to use an OIDC authenticating proxy for securing an on-prem, airgapped Kubernetes Cluster. For an OIDC Provider, we use Dex, which lives in the same cluster and connects with LDAP. Keycloak Gatekeeper is a great project that has caught our attention and we would love to use it to cover our use-case. We have the following user requirements: - Don't make any requests that exit and reenter the cluster. This means that the OIDC Client should talk to the OIDC Provider using its internal address. - Work behind any origin URL. This lets users use kubernetes port-forward to debug issues and work behind a proxy. To solve these requirements we came up with the following: - Use the OIDC Provider's internal address for the {discovery, jwks, token, userinfo}_endpoint. This means the OIDC Client won't make a request to a public address that would exit and reenter the cluster. - Use relative URLs for the authorization_endpoint and redirect_uri. We know that our OIDC Client and OIDC Provider live behind the same origin, so we can redirect from one to the other using relative URLs. We haven't found a way to set up Gatekeeper to support this use-case. I would greatly appreciate it if you could help me understand if this is a valid use-case for Gatekeeper to support. If yes, I'd love to contribute to it and if not, I'd like to understand why. Thanks in advance, Yannis Zarkadas