Getting "SSO failed" after successfully logging into Keycloak

[evgeni]

@eleneshector

I noticed there was a “foreman-openidc_oidc_keycloak_Foreman_Realm.conf” file under “/etc/apache2/conf.d/” but it was empty. Not sure if thats expected.

So I ended up moving the “foreman-openidc_oidc_keycloak_Foreman_Realm.conf” file from “/etc/httpd/conf.d/” and replacing the empty file under “/etc/apache2/conf.d/”

I think this is what was discussed in the following thread:

"SSO Failed" error while integrating with Keycloak

I spoke to tbrisker on the IRC channel who helped me find the issue. We looked at a couple things and he suggested that it was likely to be an Apache config issue. He was correct; on Debian-based distributions Apache is installed to /etc/apache2, while on RedHat-based distributions it is installed to /etc/httpd. The foreman-installer package accounts for this and installs Apache to the correct folder. However, the keycloak-httpd-client-installer does not account for this difference and just ins…

GitHub - jdennis/keycloak-httpd-client-install: Python support for Keycloak doesn’t know that on Debian the config is in /etc/apache2 vs /etc/httpd (like on CentOS), and miss-places it.

@eleneshector

I crossed my fingers and attempted to login using my Keycloak credentials, and it worked! I’m still not sure whats different between my existing Foreman instance (that I upgraded from 1.24 → 2.5.2, version after version) and my new 2.5.2 test instance.

I think it’s the RequestHeader set REMOTE_USER %{REMOTE_USER}e and friends from the Apache config I posted above.

To elaborate a bit more on the architecture behind our setup and “how it should work”:

• We used to deploy Foreman with Passenger as an Apache module, which meant that the Foreman application ran inside the Apache process and had access to environment variables Apache and its modules set.
• This is also how most of the mod_auth_something modules work: you configure them to talk to some kind of authentication service (Kerberos, Keycloak, you name it) and after the authentication succeeded they set a few environment variables to let “the rest of the stack” (other modules, applications, etc) know who is logged in.
• With Foreman 2.1 we moved the deployment to Puma, which is running as a standalone process and Apache is talking HTTP to it. That especially means that any application running inside Puma can’t access environment variables from Apache, thus breaking authentication.
• With Foreman 2.3 we fixed that by forwarding the relevant variables as HTTP headers.

And I think the last bit was missing in your setup, and was now corrected by the installer.