Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keycloak absolute URL for quarkus.oidc.authorization-path property #17130

Closed
Jojal opened this issue May 10, 2021 · 3 comments · Fixed by #17210
Closed

Keycloak absolute URL for quarkus.oidc.authorization-path property #17130

Jojal opened this issue May 10, 2021 · 3 comments · Fixed by #17210
Assignees
Milestone

Comments

@Jojal
Copy link

Jojal commented May 10, 2021

Description

As a developer running keycloak in a kubernetes pod and my Quarkus application in a second pod, it would be great to have the possibility to specify the quarkus.oidc.authorization-path in an absolute way in order to override the quarkus.oidc.auth-server-url which is an internal kubernetes URL.
This case should happen only for the redirection to display the login page to the user.

Justification

Working with kubernetes with this configuration :

quarkus.oidc.auth-server-url=http://keycloak-http.authentication.svc.cluster.local/auth/realms/quarkus

We can see the url is pointing to authentication.svc.cluster.local which is the URL of the Keycloak POD only accessible from the Quarkus Application POD. (i mean not accessible from outside)
Unfortunatly, when if we set the quarkus.oidc.application-type to web-app, we need a redirection to display the login page to the user. With this basic configuration, the redirection will happen to a kubernetes url authentication.svc.cluster.local which is not accessible from the user browser.

That way, if we could just put an absolute URL in the quarkus.oidc.authorization-path property, the redirection would happened correctly.

@Jojal Jojal added the kind/enhancement New feature or request label May 10, 2021
@quarkus-bot
Copy link

quarkus-bot bot commented May 10, 2021

/cc @geoand, @pedroigor, @sberyozkin

@sberyozkin sberyozkin self-assigned this May 11, 2021
@sberyozkin
Copy link
Member

sberyozkin commented May 11, 2021

I was thinking for a moment that simply starting KC with KEYCLOAK_FRONTEND_URL set to the publicly accessible URL would do it since authorization_endpoint would be KEYCLOAK_FRONTEND_URL based - but so would also be the jwk path and token endpoints - which as you implied in the Zulip thread would not be accessible from the pod running the endpoint...

@sberyozkin
Copy link
Member

sberyozkin commented May 12, 2021

As confirmed by @Jojal KEYCLOAK_FRONTEND_URL works so I'll close this issue with a small PR adding a note about KEYCLOAK_FRONTEND_URL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants