Category: IAM

Using Keycloak Identity Provider for Rancher SSO

In Rancher 2.1.0 they added support for SAML authentication with Keycloak. What this means is Rancher will use a Keycloak realm to authenticate users.

This means that there is one place to manage users for a host of your applications. It also means that if they have logged on to the realm with their browser they can have single sign on to rancher - ie. they will already be logged into rancher.

The documentation on Rancher setting up Keycloak auth is already pretty good, however certain things can get tricky espescially if you are using Keycloak 7 and up.

So let's jump in and set it up...


  • A Keycloak Identity Provider Setup
  • A Rancher Instance

Setting up the Rancher Client on Keycloak

In keycloak you already have a realm and user's eith local or federated from LDAP.

So now we need to create the client for Rancher.

Go to Clients -> Create:


Now add the following extra settings (replace the white box with your Rancher URL):

keycloak-saml-client-for-rancher-config-1keycloak-saml-client-for-rancher-config-2Boom, we've setup the keycloak side. Now we just need to export this config to load onto the rancher side.

Usually this would be done on the Installation tab of the client. However rancher wants the SAML Metadata IDPSSODescriptor but Keycloak 7 does not provide that.

The way to get it is to go to this URL:


and save that XML to a file.

You then need to copy all the properties of EntitiesDescriptor and add them to the first EntityDescriptor.  Then delete the EntitiesDescriptor element.

Now save that and it will be the config to import.

Setting up Keycloak Auth on Rancher

Open Rancher on the Global scope and select Security -> Authentication:


You will get a few authentication / identity provider options:


Select Keycloak and you will need the following information.

Field Description
Display Name Field The AD attribute that contains the display name of users.
User Name Field The AD attribute that contains the user name/given name.
UID Field An AD attribute that is unique to every user.
Groups Field Make entries for managing group memberships.
Rancher API Host The URL for your Rancher Server.
Private Key / Certificate A key/certificate pair to create a secure shell between Rancher and your IdP.
IDP-metadata The metadata.xml file that you exported from your IdP server.

These AD Attributes are set on the Keycloak side at Client -> Mappers, the best thing to do is add builtin on the rancher side:

That will add the defualt attributes and it is best to add those, however for access to the groups of the user you need to map a group list attribute.


You would use the protocol mapper below, to map the member attribute on rancher side to a user's group list.



So to view the SAML attribute name just open one of the mappers and use the Friendly Name.

In my case:

Display Name Field: givenName
User Name Field: email
UID Field: email
Rancher API Host: https://yourRancherHostURL:5443
Groups Field: member


If successful you will be presented with this screen. If you are not successful and you have the invalid SAML attributes error, then you need to fix your attribute names.

If you only want to allow members of certain groups on the keycloak realm then you can change the options below:


So How has Our Lives Improved Since Implementing SSO

  • A central place for authentication, you don't need to manage much about auth on your application side.
  • Deletage auth and turn Time-based One Time Pin, Add terms and conditions and giving access with a simple button switch.
  • You get SSO (single sign on): sign on to the realm and now you can simply press the login button on any other linked client and you will be logged in.
  • Single sign off - I tested this and it did not work. Logging out of one client kept you in the other client.

Single Sign Out

During my testing single sign out was not working. However I must mention my setup was 3 parts:

  • Keycloak on a VM accessible only on the local network
  • A Django App in a docker container on my local machine
  • Rancher also accessible on the local network

So my guess is that when using the front channel (browser) for the authentication step on the django client, it works because the redirect from the client goes to the docker container.

However when the logout is sent on the backchannel, it can't access as there isn't a proper DNS entry.

What I am going to do is deploy the docker container on Openshift (god bless my soul)...and set an ip or dns so that keycloak can access it on the back channel.




OpenID Connect Clients for Python

What OpenID Connect clients are available for python?

If we look at the certified implementations for python:

However I also found this one:

The Mozilla one has nicer docs and a nicer readme, so I'm going to start with that. They also have some info on OpenID Connect and seem to know what they are doing. Also I'm using Django So it will plug right in.

Note: django-oidc-provider is not a client - it is a provider. If you are already using an identity provider like Keycloak or WSO2, you don't need this.

Take a full look at all available django oidc clients on django packages.

Provider Side Configuration

On the provider side you need to create a client and set the relevant settings.

Ensure the access type is confidential so that you can set the required settings on django side:OIDC_RP_CLIENT_ID and OIDC_RP_CLIENT_SECRET

The next thing you need is the settings for keycloaks endpoints, luckily you can easily get it from a url:


So you can now set these values:


The default algorithm is HS256 on the mozilla side.

self.OIDC_RP_SIGN_ALGO = self.get_settings('OIDC_RP_SIGN_ALGO', 'HS256')

If you don't change that you will get a Suspiscious error:


Oh also you don't need to put OIDC_RP_IDP_SIGN_KEY in your settings, the library will figure that out for you.




Open-Source Single Sign-On (SSO) and IAM


On wikipedia  you can get a list of all SSO platforms / frameworks, you can view the licenses of the products on there. You will see there are so many proprietary solutions and it makes it difficult as they are harder to test out.

We are trying to solve the problem of having one a single user and security systems making maintenance and security easier.

Furthmore, you don't have a community of people looking at the code and finding bugs and security issues with the implementation. I also don't like the model of only giving certain features to paid users - I mean security is ubiquotous and fundamental.

Some of the proprietary players:

  • Gluu
  • Okta
  • Auth0
  • Amazon Cognito
  • Aerobase

Some of the open source projects are old and difficult to test out.

Open Source Project:

However some king soul has created a gist comparing open source Single sign-on and IAM solutions. I have added the table below in case the author decides to delete it:

 AerobaseKeycloakWSO2 Identity ServerGluuCASOpenAMShibboleth IDP
OpenID Connectyesyesyesyesyesyesthird-party
Multi-factor authenticationyesyesyesyesyesyesyes
Admin UIyesyesyesyesyesyesno
Identity brokeringyesyesyes
MiddlewareNGINX, WildflyWildfly, JBOSSWSO2 CarbonJetty, Apache HTTPDany Java app serverany Java app serverJetty, Tomcat
Commercial supportyesnoyesyesthird-partyyesthird-party
Installation Difficultyeasyeasy (docker on openshift)hard
First Release20142008

It is also important to look at the OpenID Certification and ensure the product or project you choose has been certified.

That is important as there are pretty much 2 single sign-on protocols: SAML and OpenID Connect.

For me there are 2 clear winners: Keycloak and WSO2.

Update: Oops I though that Django-oidc-provider was an openid client - but it is not, it is a provider. It is in the same category as Keycloak, WSO2 and Dex. I haven't dug too deep on it - just installed it.


  • Keycloak is a an opensource version of commercial derivative of Red Hat SSO which costs $8000 a year.
  • No patches for the Community Version
  • Users, Roles and Groups
  • User Stores: Single data source
  • Single sign-on: SAML2 and OpenID Connect
  • Fully featured attribute mapping
  • No per-application identity provider
  • Only inbound user provisioning
  • Superuser can manage all realms
  • OTP: Timebased OTP (TOTP), Counter-based OTP (HOTP) and Google Authenticator QR code
  • Multistep Auth: Limited with a set of predefined actions like Update password, terms and condition etc.
  • Easier, userfiendly with modern UI
  • Funcationality more rigid

WSO2 Identity Server

  • Commercial support at 19320 Euros a year.
  • No patches for the community version
  • Users and Roles only
  • User Stores: Mulitple data stores
  • Single sign-on: SAML2 and OpenID Connect
  • Fully featured attribute mapping
  • Has per-application identity provider
  • Inbound and outbound user provisioning with per-applicaiton config
  • Superuser cannot manage all tenants - only tenant admin
  • OTP: SMS, Email, Timebased OTP (TOTP) and Google Authenticator QR code
  • Multistep Auth: More flexible + complexity
  • Harder to install and configure, UI is a bit old
  • Functionality very open