Keycloak

Using mod_auth_openidc with Keycloak

Keycloak and mod_auth_openidc is a great fit for self hosted authentication with user administration. Official docs contains a guide.

One can use mod_auth_openidc as an OpenID Connect Relying Party with Keycloak, which is described hereafter, or one can use it as an OAuth 2.0 Resource Server, whose setup is described at https://github.com/pingidentity/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server#keycloak.

There's a sample setup for local OpenID Connect testing using Docker at https://github.com/Reposoft/openidc-keycloak-test.

You create an openid-connect type "client" in your Keycloak realm. Set access type to "Confidential", get a secret, put that secret in a conf with something like:

	OIDCProviderMetadataURL https://keycloak.example.net/auth/realms/Testrealm/.well-known/openid-configuration
	OIDCRedirectURI https://myserver.example.not/oauth2callback
	OIDCCryptoPassphrase 0123456789
	OIDCClientID testclient
	OIDCClientSecret ca446a2d-a65f-4e84-95a7-d20eb36989d8
	# See https://github.com/Reposoft/openidc-keycloak-test/issues/7
	OIDCProviderTokenEndpointAuth client_secret_basic

	OIDCRemoteUserClaim email
	OIDCScope "openid email"

Without an OICDRemoteUserClaim you'd get usernames like [user-uuid]@[keycloak-realm-url] which is unuseful. E-mail works well with Keycloak: user@example.net can authenticate as both user and the full address.

Single Sign On (SSO) works. Just duplicate your config in multiple VirtualHosts or httpd instances and modify the OIDCRedirectURI accordingly. You can add multiple "Valid Redirect URIs" in the Keycloak admin ui.

Roles

To leverage realm_access_role roles defined in Keycloak, make sure that Keycloak returns those claims from the user info endpoint rather than associating them with the access token (or even putting them in the ID token). To make sure that role information is accurate and up-to-date you can use OIDCUserInfoRefreshInterval.

Find below a thread on the e-mail list that reflects that:

Aha! I worked out how to configure what's in the user info in Keycloak.

Now the userinfo endpoint is returning:

{"sub":"e87ee895-e345-431e-8c94-2197655fc9d5","realm_access_role":["crm_user","rt_user","offline_access","uma_authorization"],"email_verified":false,"name":"Hamish Moffatt","preferred_username":"hamish","given_name":"Hamish","family_name":"Moffatt","email":"..."}
           
Now I can access that as "require claim:realm_access_role:crm_user" (and that same claim isn't in the ID token).

So with the addition of OIDCUserInfoRefreshInterval, all should be good now without the need to expire the sessions quickly.


Thanks!
- hide quoted text -
Hamish


On Thursday, 21 March 2019 21:26:32 UTC+11, Hans Zandbelt wrote:
that's not the correct solution but a workaround to achieve something that you should not aim for

really: roles should be provided as part of the userinfo response; the fact that Keycloak is not able to do that (or is it by now?) is unfortunate and due to a misunderstanding on the protocol/spec as discussions in the past with the Keycloak developers have shown

Hans.

On Thu, Mar 21, 2019 at 11:23 AM Hamish Moffatt <hamish....@gmail.com> wrote:
I changed my roles in Keycloak but mod_auth_openidc did not pick this up until I let the session expire (300 second default timeout). It seems like the ID token is never refreshed.

So unless I can access the claims in the access token, the correct solution is "OIDCSessionMaxDuration 0".


Hamish

On Thursday, 21 March 2019 20:51:26 UTC+11, Hamish Moffatt wrote:
Sorry, I'm not explaining myself too well. I'm using Keycloak and it's sending extra information in the access and ID tokens.

  "realm_access": {
    "roles": [
      "crm_user",
      "offline_access",
      "uma_authorization"
    ]
  },

I'm able to "require claim realm_access.roles:crm_user" which picks this up from the ID token.

Q1. When does mod_auth_openidc refresh the ID token?

Q2. Can I access claims from the access token instead?


Hamish



On Thursday, 21 March 2019 20:18:50 UTC+11, Hans Zandbelt wrote:
I don't know what "changes to realms in the token" refers to but if you want to pickup updated user information from the user info endpoint you'd have to use the refreshed access token against that and thus use OIDCUserInfoRefreshInterval indeed (which obsoletes the need for OIDCRefreshAccessTokenBeforeExpiry)

Hans.

On Thu, Mar 21, 2019 at 9:51 AM Hamish Moffatt <hamish....@gmail.com> wrote:


On Thursday, 21 March 2019 19:39:49 UTC+11, Hans Zandbelt wrote:
I'd use 
OIDCRefreshAccessTokenBeforeExpiry 10

 
OK. Will that also pick up changes to the realms in the token, do I also need OIDCUserInfoRefreshInterval ?