Bug 2062365 - khci won't work with Quarkus-based Keycloak due to missing /auth path
Summary: khci won't work with Quarkus-based Keycloak due to missing /auth path
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: keycloak-httpd-client-install
Version: 8.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Halman
QA Contact: Scott Poore
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-09 16:16 UTC by Jakub Hrozek
Modified: 2023-08-10 07:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-115050 0 None None None 2022-03-09 16:21:56 UTC
Red Hat Issue Tracker SSSD-4676 0 None None None 2022-05-17 14:38:36 UTC

Description Jakub Hrozek 2022-03-09 16:16:05 UTC
Description of problem:
Since Keycloak switched to Quarkus, they also deprecated the /auth endpoint, used by khci. See more at: 
https://www.keycloak.org/migration/migrating-to-quarkus

Version-Release number of selected component (if applicable):
the latest we have in RHEL-8

How reproducible:
not sure yet

Steps to Reproduce:
1. enroll a httpd server with mod_auth_openidc (git grep shows that the /auth endpoint is only used for OIDC)
2.
3.

Actual results:
probably doesn't work

Expected results:
should work

Additional info:

Comment 1 Scott Poore 2022-03-14 22:46:00 UTC
I think we should use --http-relative-path to match the new option in Keycloak.  In Keycloak this option allows you to add /auth back to the path to help with Migrating from older versions of keycloak that needed it.

I opened a ticket with Keycloak asking how to use that option in production mode.  I was informed that you either have to use it with build stage first or add the --auto-build option to the start stage.  This also applies with starting the Keycloak container in production mode.  The solution I took with my tests was to just add --auto-build and --http-relative-path to the contain run start command like this:

podman run --name keycloak -d \
    -p 8080:8080 \
    -p 8443:8443 \
    -e KEYCLOAK_ADMIN=admin \
    -e KEYCLOAK_ADMIN_PASSWORD=MyPassword123 \
    -e KC_LOG_LEVEL=debug \
    -e KC_HOSTNAME=$(hostname):8443 \
    -e KC_HTTPS_CERTIFICATE_FILE=/etc/x509/https/tls.crt \
    -e KC_HTTPS_CERTIFICATE_KEY_FILE=/etc/x509/https/tls.key \
    -e KC_HTTPS_TRUST_STORE_FILE=/etc/x509/https/truststore.keystore \
    -e KC_HTTPS_TRUST_STORE_PASSWORD=MyPassword123 \
    -e KC_HTTP_RELATIVE_PATH=/auth \
    -v /tmp/https:/etc/x509/https:Z \
    quay.io/keycloak/keycloak:latest start --auto-build

You'll note I used the KC_HTTP_RELATIVE_PATH environmental variable instead of the cli arg.

For reference, this is the ticket I opened upstream asking about using that option in production mode:

https://github.com/keycloak/keycloak/issues/10699


Note You need to log in before you can comment on or make changes to this bug.