Keycloak Cluster

As resilient as our docker build is I’d like to extend it to a clustered instance of Keycloak. This way, I can load balance a pair of docker containers and maintain an even higher uptime. The model I’ve chosen is the standalone HA method. This gives me two Keylcoak instances and a single back end database.

I wanted to build this across a data centre in two different virtual hosts, connected to the same network. I’m also going to replicate the postgres database between systems using repmgr.

First thing is to prepare the environment and allow firewall connections between the virtuals on TCP ports 5432 (for postgres) and TCP port 7600 (for Keycloak TCPPING). Then I need acess to TCP port 8080 (for the Keycloak web interface) from the load balancer. I’ll be using TLS termination on the load balancer/reverse proxy to handle the certificates.

PAM and OAuth2

We’re looking for a way to get our remote users authenticating with the office systems whilst they are on the road, or in these troubled times working from home.

Not wanting to expose our LDAP to the internet it would be worth looking at using the existing Open Source OAuth2 solution we have – Keycloak.

Keycloak and OpenLDAP

After getting Keycloak up and running, it’s a breeze to connect it to LDAP and use the users from there, but there were a few things I missed about group membership and there’s a fun quirk to fix about the user name.

Synchronising Users

First task after creating a new realm is to go to User Federation and add an LDAP provider. Fill in all you details for the LDAP server – I’d advise you to use an account that has writeable access to your people OU at least. This is so you can leave Keycloak to manage your users and let them have a self-service portal for changing their passwords.

Keycloak Container Set

Single Sign On from a simple docker container set.

The container might be simple but the complexities of OAuth2, SAML and identity services are far from straight forward. For some time we’ve been using applications that can provide OAuth2 services as authenticators. This needed to change as we were looking to broaden the capabilities of our authentication processes to encompass 3rd parties and various authentication realms – from trusted, untrusted and community sources.

MediaWiki and OAuth2

With a move to a more joined up authentication using Single Sign On (SSO) I deployed a Keycloak service in a docker container – that should probably form part of a later article.

Keycloak provides the bridge between OAuth2/SAML and LDAP authentication. Rather than relying on the same passwords and having to type the same credentials time and again, into various corporate applications, we can now setup the application with a client in keycloak and use tokens across authentication our landscape.

As we use MediaWiki for the bulk of our corporate knowledge it made sense to add in Single Sign On.