Exploration of single sign on functionality

An increasing number of our customer organisations need an option to involve their constituents when providing services to them or asking constitutents to contribute or support them. For that purpose, we have been building portals and over the recent year have also included the file storage options that Nextcloud provides. One of our clients also considers adding Moodle to the set of applications to involve their supporters.

We build those solutions with Drupal acting as a login server. Though Drupal can be set up – with an adjustment here and there – to provide a single sign on solution it has its challenges, and it is not its primary task. We also heard about KeyCloack as an open source tool for identity and access management and were curious if this would work in our context.

To find out the pro’s and cons, we did an exploration of single sign on functionality last month based on KeyCloack, where we use this as a a separate identity provider for logging into CiviCRM and other applications.

Goal was to detect how easy such a setup would be, what issues we might run into, what needs to be developed before it can be used in a production ready system. Another goal was to gain knowledge about single sign on protocols (such as Open ID or Saml).

The setup

In the setup KeyCloak would function as the user database and the login platform.

And the three applications that we tested with the login functionality were:

• Nextcloud for file storage
• CiviCRM for the CRM part
• Drupal as a portal / dashboard for constituents

Use case

When the user wants to access CiviCRM, Nextcloud or the portal, the application checks with KeyCloak whether the user is already logged in. If not the user gets redirected to KeyCloak where the user enters an email-address and receives a one time only password. After receiving the password and entering it the user is logged in (in all three applications).

We also wanted to check whether logging out of applications works. (So if a user logs out of one application they are logged out of all of them).

Outcome

• The outcome is that we like KeyCloak as it is good in what it does. It provides screens for configuration (and there is a lot that can be configured through the UI). We also think that sometimes KeyCloak is too complex to setup and manage for certain projects/clients. It is written in Java (and it runs in a Docker).
• It depends on the exact use case whether KeyCloak would be adviced by us or whether to use Drupal as the identity provider. For example if a client has an IT person who is good at managing a php webserver then it is easier to stick to Drupal. But if the IT person managing the stack is also able to manage other services then KeyCloak might be good.
• Regarding the log out functionality: we discovered that neither Drupal nor Nextcloud really implement this well. CiviCRM Standalone does implement logout functionality. (For the techies we used Front Channel Logout).

Whishlist

During our exploration we also came up with a whishlist, things we want but we did not explore nor develop.

• Automatic creation of users in KeyCloak when a certain condition is met in CiviCRM. E.g. the person becomes a volunteer of your organisation, or the person is a member. CiviCRM is the database with your constituents and we think it is the constituents we want to give access to portals, nextcloud and other tools. (Of fcourse, this should also include disabling the account when a user does not have the rights anymore). We did investigate this theoretically. We can use the KeyCloak api to create users from CiviCRM into KeyCloak. Or we can develop a plugin for KeyCloak to lookup a user in CiviCRM.
• Roles and access management. We did have a short look into roles. KeyCloak can manage roles. And then it depends on the setup of the client (e.g. Nextcloud, Drupal or CiviCRM) whether the user gets the correct roles and permissions. With Nextcloud we would like to have some sort of access list. As we did some setups in the past where a user only has a access to a certain directory in nextcloud when he or she has a role on the CiviCRM Case. (We did solve this at a real use case but it has a caveat because it assumes that all users exists in the Nextcloud database before handing out the permission).
• Element/Matrix as a chat application and logging in through KeyCloak. We looked it up in the documentation and Element/Matrix supports OpenID and KeyCloak.

Final words

We did enjoy this exploration and we have learned quite a bit off it. This blog post is to share our outcomes with the wider CiviCRM community. It did not lead to a direct off the shelf solution. However it helped us to serve our clients better because we have a better understanding of the single sign on flow. And when we would have a client where a robust single sign on solution is needed we might go forward with developing the missing bits.