Category: Integration

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.




continuous integration: Jenkins Automated Deployments with a Private git server

What is Jenkins?

A continuous integration tool written in Java. Continuous integration is the process of merging development work among multiple developers. It also serves to automate unit testing and I am certain other types of testing in test driven development.

To simplify all that, it is build automation and in my opinion an automated deployment system (preferably for testing, q&a and staging).

jenkins continuous integration debian setup

Pros: Jenkins

  • Works with Git
  • Webhook from git can build/deploy/test after each commit
  • Multiple plugins available to integrate with development tools/project management
  • Web Interface...I guess this is a pro
  • Can employ scripts to run after successful builds
  • Rollback...not sure...

Where I have enjoyed the benefits is that if you use git for versioning and yuou are making multiple commits, there is an instantaneous test and deploy after each commit. Rather than the wasteful approach of commiting on local dev, pushing to remote, logging in to testing server, pulling from repo, testing; after every commit.


Theother open source alternatives are:

Setting up Jenkins Automated Deployments with your own Git Server

Haven't created your personal git repo yet? Try this tutorial or a better one.

Setting up Jenkins on Debian:

wget -q -O - | sudo apt-key add -
sudo sh -c 'echo deb binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

As far as I know that is it, provided you have apache installed...
Navigate to...


The first thing you should do is lock down Jenkins so only you can access it

Jenkins->Manage Jenkins->Configure Global Security

Setup security as you wish, you will need to manage users for this too.

Now I am assuming you are using git for source control, if you are not you are wrong.

For a non-managed git server, ie. a private git server you have setup yourself you will need to add the git plugin in Jenkins.

Manage Jenkins -> Manage Plugins -> Install the GIT plugin

Now create an ssh key for jenkins:

sudo su jenkins
ssh-keygen -t rsa -C ""
It should install to /var/lib/jenkins/.ssh

Copy the public key, of the ssh key pair.
append that public key to your git server's git user's authorizes_keys


Should be sorted now, but hold on to the key you will need it.

Create a new item, add project name and click freestyle project.

Jenkins -> New Item -> Freestyle Project


Source Code Management



and add the git repo details along with the public key created earlier.

jenkins deploymentWhat Next

Well you build and it should be good. It builds to:


So things to do and I might update this post is:

1. Setup a script to copy the build to document root (staging / live site)...but why is this required? Furthermore shouldn't the testing be done in a hosted environement, specifically end-to-end tests?
2. Setup a webhook (from the private personal git repo, and not github) to tell jenkins there has been a commit to master....

Another top article on Setting up Jenkins



With regards to 2. Setting up a webhook, or push based builds using jenkins take a look at the below site:

We need to set Jenkins up to trigger builds remotely:

trigger builds remotely scripts git jenkins

Then create a script (name it: post-receive in /your_bare_repo.git/hooks/.) with the token you just created:

I didn't need a username and password but I think it would be advisable to have a more secure method instead of jsut the token, because analytics tracking and server logs would have logged that query string parameter, and someone could potentially bombard your system with builds constantly.

/usr/bin/curl -s \


You may have an issue with authentication, if so view the jenkins scripted clients page.

Now we may need to look at testing deployments and copying to web server if successful.