Single sign-on (SSO) offers many advantages, and SSO providers can provide valuable services in terms of user account security. Although each user only needs to remember one password to access different services (which is not to be confused with a user simply using the same password for different services), the providers themselves do not have any knowledge of the password used. If a data leak occurs in one of the services, passwords will not fall easily into the hands of criminals. The service exclusively relies on the SSO provider to verify the user's identity securely. For some providers, the identity itself is not important, the only important thing is to identify the same person beyond any doubt.

To use SSO, you are not dependent on the three major players, Google, Facebook, or OpenID. Although you have a number of smaller and specialized providers from which to choose, you can also set up an SSO service yourself. Often the commercial "Atlassion Crowd" SSO server is used, which acts as the authentication center for Atlassian's own services (e.g., Jira, Confluence, Bitbucket). If you want to set up your own server, you can also start with the open source alternative Keycloak [1]. The software, developed by Red Hat, has been around since 2014 and is currently being developed under the umbrella of the JBoss application server.

DIY SSO

The advantage of operating an SSO server like Keycloak yourself is that you can include virtually any existing directory service. Your users can then use the same credentials as on their domain machines or for accessing email. As the client protocol, Keycloak supports OpenID Connect or the somewhat older SAML (security assertion markup language). If you have the choice, the Keycloak developers recommend OpenID Connect, which is an extension of OAuth 2.0 and offers JSON web tokens, among other things.

To test Keycloak, you can use Docker container version 11 [2], as used for this article, although at print, version 12 was current. To launch the container, use the command:

docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=it-administrator quay.io/keycloak/keycloak:11.0.0

Change the username and password to suit your needs. In addition to the two environment variables specified, the container offers a variety of other configuration options [3], starting with the selection of the database backend and the integration of TLS certificates, as well as clustering options for high availability. As soon as the container has started up, you can use your browser to access the welcome page at http://localhost:8080/ . Now select Administration Console and log in with the selected user ID.

Configuration

First, familiarize yourself with the interface and adjust the basic configuration in Realm Settings . For example, if you have enabled TLS and want to make it mandatory for logins, check the box in Login | Require SSL . To configure an email account for Keycloak communications, go to Email . Again, you will want to use TLS or StartTLS. To protect Keycloak against attacks, you can also enable brute force detection under Security Defenses . As with Fail2Ban, you can configure different parameters after enabling.

In the Clients section, configure the applications that Keycloak can use for authentication by assigning a unique name for the application and the client ID, selecting the protocol, and entering the base URL, which must be prefixed with relative paths. Once you have saved your input, you will be taken to other application settings where you configure valid URLs for forwarding after a successful login, the lifetime of issued tokens, or – under Client Scopes – the attributes and properties of the users your application can access. In the standard case, all client scopes are assigned first. Other configuration of services and the need to access individual user attributes can be adapted to your environment, and access can be tested.

Integrate LDAP

Before you use an LDAP directory as a backend for authentication, you can already create users in the Users menu item. Therefore, Keycloak can theoretically even be used without a directory service in the background. To include an LDAP directory, go to User Federation and select Ldap from the drop-down list. In the following dialog, enter the connection settings for your LDAP server.

The recommendation for testing purposes is to set the Edit mode to READ_ONLY first, so you do not overwrite any settings in your directory. If you want to synchronize new registrations through Keycloak with LDAP, check the Sync Registrations box. Now select your LDAP backend type (e.g., Active Directory ); some default settings will be entered for you.

Next, complete the settings marked with a red asterisk. You can accept the suggestions for the attributes first, unless you have defined non-default attributes in your LDAP. You can enter the Connection URL and schema (e.g., ldaps://ldap.example.org:636/ for a TLS-secured connection); then, click Test Connection to check the connection to the LDAP server. Now define the location of the users in the LDAP tree, configure a user with appropriate permissions, test access, and save your changes.