Support for Keycloak as an Advanced Identity Manager

Available from version 2.3.0-immortal


In Q4 we will incorporate Keycloak as an advanced Identity Manager, for those scenarios where a more advanced and customized configuration is needed: multiple user repositories and authentication providers (user federation), integration with other IM’s (identity brokering), authentication and session flow customization...

The following is a detailed description of how the integration with this Open Source IM has been approached. Nevertheless, this is but a first approximation and, as everything that is integrated into the platform, it is subject to change as we collect feedback from products and projects.

Keycloak Glossay

Below there are terms within Keycloak:

  • Admin Console: Web-based GUI where you can “click out” all configurations required by your instance to work as you desire. 

  • Users: Entities that are able to log into the protected system. They have a set of editable attributes and can be a part of a group and/or have specific roles assigned to them.

  • Role: A type or category of user that exists within an organization. Applications often base on roles to restrict access to resources.  

  • Groups: Entities that are used to manage a set of users. Similarly to users, groups have editable attributes and you can also assign roles to a group. Users that become members of a group inherit their attributes and roles.

  • Realm: A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control.

  • Client: Entities that can request Keycloak to authenticate a user. Most often, clients are applications and services which want to use Keycloak to secure themselves. Clients may also be entities wanting to request identity information or an access token so that they can securely invoke other services secured by Keycloak.

  • Identity Token: A token providing identity information about the user. Part of the OpenID Connect specification.

  • Access Token: A token that can be provided as part of an HTTP request. 

Keycloak Realms

Keycloak Realms will correspond to the Platform’s verticals, so that, in a Multitenant environment, each client has its own Keycloak Realm, which is ultimately an independent instance. They can configure that Realm according to their needs without affecting the other Realms. Each Realm will have its own URL's, providers, clients, etc.

Keycloak Clients

Keycloak clients will correspond to the Platform’s realm concept, in such a way that the realms that are registered on the platform will be accessible for authentication via Keycloak, with the same roles, users and client secret. In a Multitenant environment, each vertical will have only the clients that correspond to it.


The default provider that will be configured in the installations with this IM will be our own, the one of the existing users in the configuration database (ConfigDB). However, it will be possible to add the "built-in" ones such as LDAP and Kerberos, and even external developments.

Advanced configuration

In addition to the integration that we offer with the platform, you can configure and extend Keycloak using the mechanisms explained in the tool's documentation: