Preface

In some of the example listings, what is meant to be displayed on one line does not fit inside the available page width. These lines have been broken up. A '\' at the end of a line means that a break has been introduced to fit in the page, with the following lines indented. So:

Let's pretend to have an extremely \
  long line that \
  does not fit
This one is short

Is really:

Let's pretend to have an extremely long line that does not fit
This one is short

Admin REST API

Keycloak comes with a fully functional Admin REST API with all features provided by the Admin Console.

To invoke the API you need to obtain an access token with the appropriate permissions. The required permissions are described in the Server Administration Guide.

You can obtain a token by enabling authentication for your application using Keycloak; see the Securing Applications and Services Guide. You can also use direct access grant to obtain an access token.

Examples of using CURL

Authenticating with a username and password

The following example assumes that you created the user admin with the password password in the master realm as shown in the Getting Started Guide tutorial.
Procedure
  1. Obtain an access token for the user in the realm master with username admin and password password:

    curl \
      -d "client_id=admin-cli" \
      -d "username=admin" \
      -d "password=password" \
      -d "grant_type=password" \
      "http://localhost:8080/realms/master/protocol/openid-connect/token"
    By default this token expires in 1 minute

    The result will be a JSON document.

  2. Invoke the API you need by extracting the value of the access_token property.

  3. Invoke the API by including the value in the Authorization header of requests to the API.

    The following example shows how to get the details of the master realm:

    curl \
      -H "Authorization: bearer eyJhbGciOiJSUz..." \
      "http://localhost:8080/admin/realms/master"

Authenticating with a service account

To authenticate against the Admin REST API using a client_id and a client_secret, perform this procedure.

Procedure
  1. Make sure the client is configured as follows:

    • client_id is a confidential client that belongs to the realm master

    • client_id has Service Accounts Enabled option enabled

    • client_id has a custom "Audience" mapper

      • Included Client Audience: security-admin-console

  2. Check that client_id has the role 'admin' assigned in the "Service Account Roles" tab.

curl \
  -d "client_id=<YOUR_CLIENT_ID>" \
  -d "client_secret=<YOUR_CLIENT_SECRET>" \
  -d "grant_type=client_credentials" \
  "http://localhost:8080/realms/master/protocol/openid-connect/token"

Example using Java

There’s a Java client library for the Admin REST API that makes it easy to use from Java. To use it from your application add a dependency on the keycloak-admin-client library.

The following example shows how to use the Java client library to get the details of the master realm:

import org.keycloak.admin.client.Keycloak;
import org.keycloak.representations.idm.RealmRepresentation;
...

Keycloak keycloak = Keycloak.getInstance(
    "http://localhost:8080",
    "master",
    "admin",
    "password",
    "admin-cli");
RealmRepresentation realm = keycloak.realm("master").toRepresentation();

Complete Javadoc for the admin client is available at API Documentation.

Themes

Keycloak provides theme support for web pages and emails. This allows customizing the look and feel of end-user facing pages so they can be integrated with your applications.

login sunrise
Login page with sunrise example theme

Theme types

A theme can provide one or more types to customize different aspects of Keycloak. The types available are:

  • Account - Account Console

  • Admin - Admin Console

  • Email - Emails

  • Login - Login forms

  • Welcome - Welcome page

Configuring a theme

All theme types, except welcome, are configured through the Admin Console.

Procedure
  1. Log into the Admin Console.

  2. Select your realm from the drop-down box in the top left corner.

  3. Click Realm Settings from the menu.

  4. Click the Themes tab.

    To set the theme for the master Admin Console you need to set the Admin Console theme for the master realm.
  5. To see the changes to the Admin Console refresh the page.

  6. Change the welcome theme by using the spi-theme-welcome-theme option.

  7. For example:

    bin/kc.[sh|bat] start --spi-theme-welcome-theme=custom-theme

Default themes

Keycloak comes bundled with default themes in the JAR file keycloak-themes-24.0.1.jar inside the server distribution. The server’s root themes directory does not contain any themes by default, but it contains a README file with some additional details about the default themes. To simplify upgrading, do not edit the bundled themes directly. Instead create your own theme that extends one of the bundled themes.

Creating a theme

A theme consists of:

Unless you plan to replace every single page you should extend another theme. Most likely you will want to extend some existing theme. Alternatively, if you intend to provide your own implementation of the admin or account console, consider extending the base theme. The base theme consists of a message bundle and therefore such implementation needs to start from scratch, including implementation of the main index.ftl Freemarker template, but it can leverage existing translations from the message bundle.

When extending a theme you can override individual resources (templates, stylesheets, etc.). If you decide to override HTML templates bear in mind that you may need to update your custom template when upgrading to a new release.

While creating a theme it’s a good idea to disable caching as this makes it possible to edit theme resources directly from the themes directory without restarting Keycloak.

Procedure
  1. Run Keycloak with the following options:

    bin/kc.[sh|bat] start --spi-theme-static-max-age=-1 --spi-theme-cache-themes=false --spi-theme-cache-templates=false
  2. Create a directory in the themes directory.

    The name of the directory becomes the name of the theme. For example to create a theme called mytheme create the directory themes/mytheme.

  3. Inside the theme directory, create a directory for each of the types your theme is going to provide.

    For example, to add the login type to the mytheme theme, create the directory themes/mytheme/login.

  4. For each type create a file theme.properties which allows setting some configuration for the theme.

    For example, to configure the theme themes/mytheme/login to extend the base theme and import some common resources, create the file themes/mytheme/login/theme.properties with following contents:

    parent=base
    import=common/keycloak

    You have now created a theme with support for the login type.

  5. Log into the Admin Console to check out your new theme

  6. Select your realm

  7. Click Realm Settings from the menu.

  8. Click on the Themes tab.

  9. For Login Theme select mytheme and click Save.

  10. Open the login page for the realm.

    You can do this either by logging in through your application or by opening the Account Console (/realms/{realm name}/account).

  11. To see the effect of changing the parent theme, set parent=keycloak in theme.properties and refresh the login page.

Be sure to re-enable caching in production as it will significantly impact performance.

If you want to manually delete the content of the themes cache, you can do so by deleting the data/tmp/kc-gzip-cache directory of the server distribution. It can be useful for instance if you redeployed custom providers or custom themes without disabling themes caching in the previous server executions.

Theme properties

Theme properties are set in the file <THEME TYPE>/theme.properties in the theme directory.

  • parent - Parent theme to extend

  • import - Import resources from another theme

  • common - Override the common resource path. The default value is common/keycloak when not specified. This value would be used as value of suffix of ${url.resourcesCommonPath}, which is used typically in freemarker templates (prefix of ${url.resoucesCommonPath} value is theme root uri).

  • styles - Space-separated list of styles to include

  • locales - Comma-separated list of supported locales

There are a list of properties that can be used to change the css class used for certain element types. For a list of these properties look at the theme.properties file in the corresponding type of the keycloak theme (themes/keycloak/<THEME TYPE>/theme.properties).

You can also add your own custom properties and use them from custom templates.

When doing so, you can substitute system properties or environment variables by using these formats:

  • ${some.system.property} - for system properties

  • ${env.ENV_VAR} - for environment variables.

A default value can also be provided in case the system property or the environment variable is not found with ${foo:defaultValue}.

If no default value is provided and there’s no corresponding system property or environment variable, then nothing is replaced and you end up with the format in your template.

Here’s an example of what is possible:

javaVersion=${java.version}

unixHome=${env.HOME:Unix home not found}
windowsHome=${env.HOMEPATH:Windows home not found}

Add a stylesheet to a theme

You can add one or more stylesheets to a theme.

Procedure
  1. Create a file in the <THEME TYPE>/resources/css directory of your theme.

  2. Add this file to the styles property in theme.properties.

    For example, to add styles.css to the mytheme, create themes/mytheme/login/resources/css/styles.css with the following content:

    .login-pf body {
        background: DimGrey none;
    }
  3. Edit themes/mytheme/login/theme.properties and add:

    styles=css/styles.css
  4. To see the changes, open the login page for your realm.

    You will notice that the only styles being applied are those from your custom stylesheet.

  5. To include the styles from the parent theme, load the styles from that theme. Edit themes/mytheme/login/theme.properties and change styles to:

    styles=css/login.css css/styles.css
    To override styles from the parent stylesheets, ensure that your stylesheet is listed last.

Adding a script to a theme

You can add one or more scripts to a theme.

Procedure
  1. Create a file in the <THEME TYPE>/resources/js directory of your theme.

  2. Add the file to the scripts property in theme.properties.

    For example, to add script.js to the mytheme, create themes/mytheme/login/resources/js/script.js with the following content:

    alert('Hello');

    Then edit themes/mytheme/login/theme.properties and add:

    scripts=js/script.js

Adding an image to a theme

To make images available to the theme add them to the <THEME TYPE>/resources/img directory of your theme. These can be used from within stylesheets or directly in HTML templates.

For example to add an image to the mytheme copy an image to themes/mytheme/login/resources/img/image.jpg.

You can then use this image from within a custom stylesheet with:

body {
    background-image: url('../img/image.jpg');
    background-size: cover;
}

Or to use directly in HTML templates add the following to a custom HTML template:

<img src="${url.resourcesPath}/img/image.jpg" alt="My image description">

Adding an image to a email theme

To make images available to the theme add them to the <THEME TYPE>/email/resources/img directory of your theme. These can be used from within directly in HTML templates.

For example to add an image to the mytheme copy an image to themes/mytheme/email/resources/img/logo.jpg.

To use directly in HTML templates add the following to a custom HTML template:

<img src="${url.resourcesUrl}/img/image.jpg" alt="My image description">

Messages

Text in the templates is loaded from message bundles. A theme that extends another theme will inherit all messages from the parent’s message bundle and you can override individual messages by adding <THEME TYPE>/messages/messages_en.properties to your theme.

For example to replace Username on the login form with Your Username for the mytheme create the file themes/mytheme/login/messages/messages_en.properties with the following content:

usernameOrEmail=Your Username

Within a message values like {0} and {1} are replaced with arguments when the message is used. For example {0} in Log in to {0} is replaced with the name of the realm.

Texts of these message bundles can be overwritten by realm-specific values. The realm-specific values are manageable via UI and API.

Adding a language to a realm

Prerequisites
Procedure
  1. Create the file <THEME TYPE>/messages/messages_<LOCALE>.properties in the directory of your theme.

  2. Add this file to the locales property in <THEME TYPE>/theme.properties. For a language to be available to users the realms login, account and email, the theme has to support the language, so you need to add your language for those theme types.

    For example, to add Norwegian translations to the mytheme theme create the file themes/mytheme/login/messages/messages_no.properties with the following content:

    usernameOrEmail=Brukernavn
    password=Passord

    If you omit a translation for messages, they will use English.

  3. Edit themes/mytheme/login/theme.properties and add:

    locales=en,no
  4. Add the same for the account and email theme types. To do this create themes/mytheme/account/messages/messages_no.properties and themes/mytheme/email/messages/messages_no.properties. Leaving these files empty will result in the English messages being used.

  5. Copy themes/mytheme/login/theme.properties to themes/mytheme/account/theme.properties and themes/mytheme/email/theme.properties.

  6. Add a translation for the language selector. This is done by adding a message to the English translation. To do this add the following to themes/mytheme/account/messages/messages_en.properties and themes/mytheme/login/messages/messages_en.properties:

    locale_no=Norsk

By default, message properties files should be encoded using UTF-8. Keycloak falls back to ISO-8859-1 handling if it can’t read the contents as UTF-8. Unicode characters can be escaped as described in Java’s documentation for PropertyResourceBundle. Previous versions of Keycloak supported specifying the encoding in the first line with a comment like # encoding: UTF-8, which is no longer supported.

Additional resources

Adding custom Identity Providers icons

Keycloak supports adding icons for custom Identity providers, which are displayed on the login screen.

Procedure
  1. Define icon classes in your login theme.properties file (for example, themes/mytheme/login/theme.properties) with key pattern kcLogoIdP-<alias>.

  2. For an Identity Provider with an alias myProvider, you may add a line to theme.properties file of your custom theme. For example:

    kcLogoIdP-myProvider = fa fa-lock

All icons are available on the official website of PatternFly4. Icons for social providers are already defined in base login theme properties (themes/keycloak/login/theme.properties), where you can inspire yourself.

Creating a custom HTML template

Keycloak uses Apache Freemarker templates to generate HTML and render pages.

Although it is possible to create custom templates to change completely how pages are rendered, the recommendation is to leverage the built-in templates as much as possible. The reasons are:

  • During upgrades, you might be forced to update your custom templates to get the latest updates from newer versions

  • Configuring CSS styles to your themes allows you to adapt the UI to match your UI design standards and guidelines.

  • User Profile allows you to support custom user attributes and configure how they are rendered.

In most cases, you won’t need to change templates to adapt Keycloak to your needs, but you can override individual templates in your own theme by creating <THEME TYPE>/<TEMPLATE>.ftl. Admin and account console use a single template index.ftl for rendering the application.

For a list of templates in other theme types look at the theme/base/<THEME_TYPE> directory in the JAR file at $KEYCLOAK_HOME/lib/lib/main/org.keycloak.keycloak-themes-<VERSION>.jar.

Procedure
  1. Copy the template from the base theme to your own theme.

  2. Apply the modifications you need.

    For example, to create a custom login form for the mytheme theme, copy themes/base/login/login.ftl to themes/mytheme/login and open it in an editor.

    After the first line (<#import …​>), add <h1>HELLO WORLD!</h1> as shown here:

    <#import "template.ftl" as layout>
    <h1>HELLO WORLD!</h1>
    ...
  3. Back up the modified template. When upgrading to a new version of Keycloak you may need to update your custom templates to apply changes to the original template if applicable.

Additional resources

Emails

To edit the subject and contents for emails, for example password recovery email, add a message bundle to the email type of your theme. There are three messages for each email. One for the subject, one for the plain text body and one for the html body.

To see all emails available take a look at themes/base/email/messages/messages_en.properties.

For example to change the password recovery email for the mytheme theme create themes/mytheme/email/messages/messages_en.properties with the following content:

passwordResetSubject=My password recovery
passwordResetBody=Reset password link: {0}
passwordResetBodyHtml=<a href="{0}">Reset password</a>

Deploying themes

Themes can be deployed to Keycloak by copying the theme directory to themes or it can be deployed as an archive. During development you can copy the theme to the themes directory, but in production you may want to consider using an archive. An archive makes it simpler to have a versioned copy of the theme, especially when you have multiple instances of Keycloak for example with clustering.

Procedure
  1. To deploy a theme as an archive, create a JAR archive with the theme resources.

  2. Add a file META-INF/keycloak-themes.json to the archive that lists the available themes in the archive as well as what types each theme provides.

    For example for the mytheme theme create mytheme.jar with the contents:

    • META-INF/keycloak-themes.json

    • theme/mytheme/login/theme.properties

    • theme/mytheme/login/login.ftl

    • theme/mytheme/login/resources/css/styles.css

    • theme/mytheme/login/resources/img/image.png

    • theme/mytheme/login/messages/messages_en.properties

    • theme/mytheme/email/messages/messages_en.properties

      The contents of META-INF/keycloak-themes.json in this case would be:

      {
          "themes": [{
              "name" : "mytheme",
              "types": [ "login", "email" ]
          }]
      }

      A single archive can contain multiple themes and each theme can support one or more types.

To deploy the archive to Keycloak, add it to the providers/ directory of Keycloak and restart the server if it is already running.

Additional resources for Themes

  • For the inspiration, see Default Themes bundled inside Keycloak.

  • Keycloak Quickstarts Repository - Directory extension of the quickstarts repository contains some theme examples, which can be also used as an inspiration. === Theme selector

By default the theme configured for the realm is used, with the exception of clients being able to override the login theme. This behavior can be changed through the Theme Selector SPI.

This could be used to select different themes for desktop and mobile devices by looking at the user agent header, for example.

To create a custom theme selector you need to implement ThemeSelectorProviderFactory and ThemeSelectorProvider.

Theme resources

When implementing custom providers in Keycloak there may often be a need to add additional templates, resources and messages bundles.

An example use-case would be a custom authenticator that requires additional templates and resources.

The easiest way to load additional theme resources is to create a JAR with templates in theme-resources/templates resources in theme-resources/resources and messages bundles in theme-resources/messages.

If you want a more flexible way to load templates and resources that can be achieved through the ThemeResourceSPI. By implementing ThemeResourceProviderFactory and ThemeResourceProvider you can decide exactly how to load templates and resources.

Locale selector

By default, the locale is selected using the DefaultLocaleSelectorProvider which implements the LocaleSelectorProvider interface. English is the default language when internationalization is disabled.

With internationalization enabled, the locale is resolved according to the logic described in the Server Administration Guide.

This behavior can be changed through the LocaleSelectorSPI by implementing the LocaleSelectorProvider and LocaleSelectorProviderFactory.

The LocaleSelectorProvider interface has a single method, resolveLocale, which must return a locale given a RealmModel and a nullable UserModel. The actual request is available from the KeycloakSession#getContext method.

Custom implementations can extend the DefaultLocaleSelectorProvider in order to reuse parts of the default behavior. For example to ignore the Accept-Language request header, a custom implementation could extend the default provider, override it’s getAcceptLanguageHeaderLocale, and return a null value. As a result the locale selection will fall back on the realm’s default language.

Additional resources for Locale selector

Identity Brokering APIs

Keycloak can delegate authentication to a parent IDP for login. A typical example of this is the case where you want users to be able to log in through a social provider such as Facebook or Google. You can also link existing accounts to a brokered IDP. This section describes some APIs that your applications can use as it pertains to identity brokering.

Retrieving external IDP tokens

Keycloak allows you to store tokens and responses from the authentication process with the external IDP. For that, you can use the Store Token configuration option on the IDP’s settings page.

Application code can retrieve these tokens and responses to pull in extra user information, or to securely invoke requests on the external IDP. For example, an application might want to use the Google token to invoke on other Google services and REST APIs. To retrieve a token for a particular identity provider you need to send a request as follows:

GET /realms/{realm}/broker/{provider_alias}/token HTTP/1.1
Host: localhost:8080
Authorization: Bearer <KEYCLOAK ACCESS TOKEN>

An application must have authenticated with Keycloak and have received an access token. This access token will need to have the broker client-level role read-token set. This means that the user must have a role mapping for this role and the client application must have that role within its scope. In this case, given that you are accessing a protected service in Keycloak, you need to send the access token issued by Keycloak during the user authentication. In the broker configuration page you can automatically assign this role to newly imported users by turning on the Stored Tokens Readable switch.

These external tokens can be re-established by either logging in again through the provider, or using the client initiated account linking API.

Client initiated account linking

Some applications want to integrate with social providers like Facebook, but do not want to provide an option to login via these social providers. Keycloak offers a browser-based API that applications can use to link an existing user account to a specific external IDP. This is called client-initiated account linking. Account linking can only be initiated by OIDC applications.

The way it works is that the application forwards the user’s browser to a URL on the Keycloak server requesting that it wants to link the user’s account to a specific external provider (i.e. Facebook). The server initiates a login with the external provider. The browser logs in at the external provider and is redirected back to the server. The server establishes the link and redirects back to the application with a confirmation.

There are some preconditions that must be met by the client application before it can initiate this protocol:

  • The desired identity provider must be configured and enabled for the user’s realm in the admin console.

  • The user account must already be logged in as an existing user via the OIDC protocol

  • The user must have an account.manage-account or account.manage-account-links role mapping.

  • The application must be granted the scope for those roles within its access token

  • The application must have access to its access token as it needs information within it to generate the redirect URL.

To initiate the login, the application must fabricate a URL and redirect the user’s browser to this URL. The URL looks like this:

/{auth-server-root}/realms/{realm}/broker/{provider}/link?client_id={id}&redirect_uri={uri}&nonce={nonce}&hash={hash}

Here’s a description of each path and query param:

provider

This is the provider alias of the external IDP that you defined in the Identity Provider section of the admin console.

client_id

This is the OIDC client id of your application. When you registered the application as a client in the admin console, you had to specify this client id.

redirect_uri

This is the application callback URL you want to redirect to after the account link is established. It must be a valid client redirect URI pattern. In other words, it must match one of the valid URL patterns you defined when you registered the client in the admin console.

nonce

This is a random string that your application must generate

hash

This is a Base64 URL encoded hash. This hash is generated by Base64 URL encoding a SHA_256 hash of nonce + token.getSessionState() + token.getIssuedFor() + provider. The token variable are obtained from the OIDC access token. Basically you are hashing the random nonce, the user session id, the client id, and the identity provider alias you want to access.

Here’s an example of Java Servlet code that generates the URL to establish the account link.

   KeycloakSecurityContext session = (KeycloakSecurityContext) httpServletRequest.getAttribute(KeycloakSecurityContext.class.getName());
   AccessToken token = session.getToken();
   String clientId = token.getIssuedFor();
   String nonce = UUID.randomUUID().toString();
   MessageDigest md = null;
   try {
      md = MessageDigest.getInstance("SHA-256");
   } catch (NoSuchAlgorithmException e) {
      throw new RuntimeException(e);
   }
   String input = nonce + token.getSessionState() + clientId + provider;
   byte[] check = md.digest(input.getBytes(StandardCharsets.UTF_8));
   String hash = Base64Url.encode(check);
   request.getSession().setAttribute("hash", hash);
   String redirectUri = ...;
   String accountLinkUrl = KeycloakUriBuilder.fromUri(authServerRootUrl)
                    .path("/realms/{realm}/broker/{provider}/link")
                    .queryParam("nonce", nonce)
                    .queryParam("hash", hash)
                    .queryParam("client_id", clientId)
                    .queryParam("redirect_uri", redirectUri).build(realm, provider).toString();

Why is this hash included? We do this so that the auth server is guaranteed to know that the client application initiated the request and no other rogue app just randomly asked for a user account to be linked to a specific provider. The auth server will first check to see if the user is logged in by checking the SSO cookie set at login. It will then try to regenerate the hash based on the current login and match it up to the hash sent by the application.

After the account has been linked, the auth server will redirect back to the redirect_uri. If there is a problem servicing the link request, the auth server may or may not redirect back to the redirect_uri. The browser may just end up at an error page instead of being redirected back to the application. If there is an error condition and the auth server deems it safe enough to redirect back to the client app, an additional error query parameter will be appended to the redirect_uri.

While this API guarantees that the application initiated the request, it does not completely prevent CSRF attacks for this operation. The application is still responsible for guarding against CSRF attacks target at itself.

Refreshing external tokens

If you are using the external token generated by logging into the provider (i.e. a Facebook or GitHub token), you can refresh this token by re-initiating the account linking API.

Service Provider Interfaces (SPI)

Keycloak is designed to cover most use-cases without requiring custom code, but we also want it to be customizable. To achieve this Keycloak has a number of Service Provider Interfaces (SPI) for which you can implement your own providers.

Implementing an SPI

To implement an SPI you need to implement its ProviderFactory and Provider interfaces. You also need to create a service configuration file.

For example, to implement the Theme Selector SPI you need to implement ThemeSelectorProviderFactory and ThemeSelectorProvider and also provide the file META-INF/services/org.keycloak.theme.ThemeSelectorProviderFactory.

Example ThemeSelectorProviderFactory:

package org.acme.provider;

import ...

public class MyThemeSelectorProviderFactory implements ThemeSelectorProviderFactory {

    @Override
    public ThemeSelectorProvider create(KeycloakSession session) {
        return new MyThemeSelectorProvider(session);
    }

    @Override
    public void init(Config.Scope config) {
    }

    @Override
    public void postInit(KeycloakSessionFactory factory) {
    }

    @Override
    public void close() {
    }

    @Override
    public String getId() {
        return "myThemeSelector";
    }
}

It is recommended that your provider factory implementation returns unique id by method getId(). However there can be some exceptions to this rule as mentioned below in the Overriding providers section.

Keycloak creates a single instance of provider factories which makes it possible to store state for multiple requests. Provider instances are created by calling create on the factory for each request so these should be light-weight object.

Example ThemeSelectorProvider:

package org.acme.provider;

import ...

public class MyThemeSelectorProvider implements ThemeSelectorProvider {

    public MyThemeSelectorProvider(KeycloakSession session) {
    }


    @Override
    public String getThemeName(Theme.Type type) {
        return "my-theme";
    }

    @Override
    public void close() {
    }
}

Example service configuration file (META-INF/services/org.keycloak.theme.ThemeSelectorProviderFactory):

org.acme.provider.MyThemeSelectorProviderFactory

To configure your provider, see the Configuring Providers guide.

For example, to configure a provider you can set options as follows:

bin/kc.[sh|bat] --spi-theme-selector-my-theme-selector-enabled=true --spi-theme-selector-my-theme-selector-theme=my-theme

Then you can retrieve the config in the ProviderFactory init method:

public void init(Config.Scope config) {
    String themeName = config.get("theme");
}

Your provider can also look up other providers if needed. For example:

public class MyThemeSelectorProvider implements ThemeSelectorProvider {

    private KeycloakSession session;

    public MyThemeSelectorProvider(KeycloakSession session) {
        this.session = session;
    }

    @Override
    public String getThemeName(Theme.Type type) {
        return session.getContext().getRealm().getLoginTheme();
    }
}

Override built-in providers

As mentioned above, it is recommended that your ProviderFactory implementations use unique ID. However at the same time, it can be useful to override one of the Keycloak built-in providers. The recommended way for this is still ProviderFactory implementation with unique ID and then for instance set the default provider as specified in the Configuring Providers guide. On the other hand, this may not be always possible.

For instance when you need some customizations to default OpenID Connect protocol behaviour and you want to override default Keycloak implementation of OIDCLoginProtocolFactory you need to preserve same providerId. As for example admin console, OIDC protocol well-known endpoint and various other things rely on the ID of the protocol factory being openid-connect.

For this case, it is highly recommended to implement method order() of your custom implementation and make sure that it has higher order than the built-in implementation.

public class CustomOIDCLoginProtocolFactory extends OIDCLoginProtocolFactory {

    // Some customizations here

    @Override
    public int order() {
        return 1;
    }
}

In case of multiple implementations with same provider ID, only the one with highest order will be used by Keycloak runtime.

Show info from your SPI implementation in the Admin Console

Sometimes it is useful to show additional info about your Provider to a Keycloak administrator. You can show provider build time information (for example, version of custom provider currently installed), current configuration of the provider (e.g. url of remote system your provider talks to) or some operational info (average time of response from remote system your provider talks to). Keycloak Admin Console provides Server Info page to show this kind of information.

To show info from your provider it is enough to implement org.keycloak.provider.ServerInfoAwareProviderFactory interface in your ProviderFactory.

Example implementation for MyThemeSelectorProviderFactory from previous example:

package org.acme.provider;

import ...

public class MyThemeSelectorProviderFactory implements ThemeSelectorProviderFactory, ServerInfoAwareProviderFactory {
    ...

    @Override
    public Map<String, String> getOperationalInfo() {
        Map<String, String> ret = new LinkedHashMap<>();
        ret.put("theme-name", "my-theme");
        return ret;
    }
}

Use available providers

In your provider implementation, you can use other providers available in Keycloak. The existing providers can be typically retrieved with the usage of the KeycloakSession, which is available to your provider as described in the section Implementing an SPI.

Keycloak has two provider types:

  • Single-implementation provider types - There can be only a single active implementation of the particular provider type in Keycloak runtime.

    For example HostnameProvider specifies the hostname to be used by Keycloak and that is shared for the whole Keycloak server. Hence there can be only single implementation of this provider active for the Keycloak server. If there are multiple provider implementations available to the server runtime, one of them needs to be specified as the default one.

For example such as:

bin/kc.[sh|bat] build --spi-hostname-provider=default

The value default used as the value of default-provider must match the ID returned by the ProviderFactory.getId() of the particular provider factory implementation. In the code, you can obtain the provider such as keycloakSession.getProvider(HostnameProvider.class)

  • Multiple implementation provider types - Those are provider types, that allow multiple implementations available and working together in the Keycloak runtime.

    For example EventListener provider allows to have multiple implementations available and registered, which means that particular event can be sent to all the listeners (jboss-logging, sysout etc). In the code, you can obtain a specified instance of the provider for example such as session.getProvider(EventListener.class, "jboss-logging") . You need to specify provider_id of the provider as the second argument as there can be multiple instances of this provider type as described above.

    The provider ID must match the ID returned by the ProviderFactory.getId() of the particular provider factory implementation. Some provider types can be retrieved with the usage of ComponentModel as the second argument and some (for example Authenticator) even need to be retrieved with the usage of KeycloakSessionFactory. It is not recommended to implement your own providers this way as it may be deprecated in the future.

Registering provider implementations

Providers are registered with the server by simply copying the JAR file to the providers directory.

If your provider needs additional dependencies not already provided by Keycloak copy these to the providers directory.

Provider JARs are not loaded in isolated classloaders, so do not include resources or classes in your provider JARs that conflict with built-in resources or classes. In particular the inclusion of an application.properties file will cause auto-build to fail if the provider JAR is removed. If you have included conflicting classes, you will see a split package warning in the start log for the server. That should be resolved by removing or repackaging the offending classes. However there is no warning if you have conflicting resource files. You should either ensure that your JAR’s resource files have path names that contain something unique to that provider, or you can check for the existence of some.file in the JAR contents under the "install root"/lib/lib/main directory with something like:

find . -type f -name "*.jar" -exec unzip -l {} \; | grep some.file

After registering new providers or dependencies Keycloak needs to be re-built with a non-optimized start or the kc.[sh|bat] build command.

Disabling a provider

You can disable a provider by setting the enabled attribute for the provider to false. For example to disable the Infinispan user cache provider use:

bin/kc.[sh|bat] build --spi-user-cache-infinispan-enabled=false

JavaScript providers

Keycloak has the ability to execute scripts during runtime in order to allow administrators to customize specific functionalities:

  • Authenticator

  • JavaScript Policy

  • OpenID Connect Protocol Mapper

  • SAML Protocol Mapper

Authenticator

Authentication scripts must provide at least one of the following functions: authenticate(..), which is called from Authenticator#authenticate(AuthenticationFlowContext) action(..), which is called from Authenticator#action(AuthenticationFlowContext)

Custom Authenticator should at least provide the authenticate(..) function. You can use the javax.script.Bindings script within the code.

script

the ScriptModel to access script metadata

realm

the RealmModel

user

the current UserModel. Note that user is available when your script authenticator is configured in the authentication flow in a way that is triggered after another authenticator succeeded in establishing user identity and set the user into the authentication session.

session

the active KeycloakSession

authenticationSession

the current AuthenticationSessionModel

httpRequest

the current org.jboss.resteasy.spi.HttpRequest

LOG

a org.jboss.logging.Logger scoped to ScriptBasedAuthenticator

You can extract additional context information from the context argument passed to the authenticate(context) action(context) function.
AuthenticationFlowError = Java.type("org.keycloak.authentication.AuthenticationFlowError");

function authenticate(context) {

  LOG.info(script.name + " --> trace auth for: " + user.username);

  if (   user.username === "tester"
      && user.getAttribute("someAttribute")
      && user.getAttribute("someAttribute").contains("someValue")) {

      context.failure(AuthenticationFlowError.INVALID_USER);
      return;
  }

  context.success();
}
Where to add script authenticator

A possible use of script authenticator is to do some checks at the end of the authentication. Note that if you want your script authenticator to be always triggered (even for instance during SSO re-authentication with the identity cookie), you may need to add it as REQUIRED at the end of the authentication flow and encapsulate the existing authenticators into a separate REQUIRED authentication subflow. This need is because the REQUIRED and ALTERNATIVE executions should not be at the same level. For example, the authentication flow configuration should appear as follows:

- User-authentication-subflow REQUIRED
-- Cookie ALTERNATIVE
-- Identity-provider-redirect ALTERNATIVE
...
- Your-Script-Authenticator REQUIRED

OpenID Connect Protocol Mapper

OpenID Connect Protocol Mapper scripts are javascript script that allow you to change the content of the ID Token and/or the Access Token.

You can use the javax.script.Bindings script within the code.

user

the current UserModel

realm

the RealmModel

token

the current IDToken. It is available only if the mapper is configured for the ID token.

tokenResponse

the current AccessTokenResponse. It is available only if the mapper is configured for the Access token.

userSession

the active UserSessionModel

keycloakSession

the active KeycloakSession

The exports of the script will be used as the value of the token claim.

// prints can be used to log information for debug purpose.
print("STARTING CUSTOM MAPPER");

var inputRequest = keycloakSession.getContext().getHttpRequest();
var params = inputRequest.getDecodedFormParameters();
var output = params.getFirst("user_input");
exports = output;

The above script allows to retrieve a user_input from the authorization request. This will be available to map in the Token Claim Name configured in the mapper.

Create a JAR with the scripts to deploy

JAR files are regular ZIP files with a .jar extension.

In order to make your scripts available to Keycloak you need to deploy them to the server. For that, you should create a JAR file with the following structure:

META-INF/keycloak-scripts.json

my-script-authenticator.js
my-script-policy.js
my-script-mapper.js

The META-INF/keycloak-scripts.json is a file descriptor that provides metadata information about the scripts you want to deploy. It is a JSON file with the following structure:

{
    "authenticators": [
        {
            "name": "My Authenticator",
            "fileName": "my-script-authenticator.js",
            "description": "My Authenticator from a JS file"
        }
    ],
    "policies": [
        {
            "name": "My Policy",
            "fileName": "my-script-policy.js",
            "description": "My Policy from a JS file"
        }
    ],
    "mappers": [
        {
            "name": "My Mapper",
            "fileName": "my-script-mapper.js",
            "description": "My Mapper from a JS file"
        }
    ],
    "saml-mappers": [
        {
            "name": "My Mapper",
            "fileName": "my-script-mapper.js",
            "description": "My Mapper from a JS file"
        }
    ]
}

This file should reference the different types of script providers that you want to deploy:

  • authenticators

    For OpenID Connect Script Authenticators. You can have one or multiple authenticators in the same JAR file

  • policies

    For JavaScript Policies when using Keycloak Authorization Services. You can have one or multiple policies in the same JAR file

  • mappers

    For OpenID Connect Script Protocol Mappers. You can have one or multiple mappers in the same JAR file

  • saml-mappers

    For SAML Script Protocol Mappers. You can have one or multiple mappers in the same JAR file

For each script file in your JAR file, you need a corresponding entry in META-INF/keycloak-scripts.json that maps your scripts files to a specific provider type. For that you should provide the following properties for each entry:

  • name

    A friendly name that will be used to show the scripts through the Keycloak Administration Console. If not provided, the name of the script file will be used instead

  • description

    An optional text that better describes the intend of the script file

  • fileName

    The name of the script file. This property is mandatory and should map to a file within the JAR.

Deploy the script JAR

Once you have a JAR file with a descriptor and the scripts you want to deploy, you just need to copy the JAR to the Keycloak providers/ directory, then run bin/kc.[sh|bat] build. Note that you also need to enable the scripts feature.

Available SPIs

If you want to see list of all available SPIs at runtime, you can check Server Info page in Admin Console as described in Admin Console section.

Extending the server

The Keycloak SPI framework offers the possibility to implement or override particular built-in providers. However Keycloak also provides capabilities to extend its core functionalities and domain. This includes possibilities to:

  • Add custom REST endpoints to the Keycloak server

  • Add your own custom SPI

  • Add custom JPA entities to the Keycloak data model

Add custom REST endpoints

This is a very powerful extension, which allows you to deploy your own REST endpoints to the Keycloak server. It enables all kinds of extensions, for example the possibility to trigger functionality on the Keycloak server, which is not available through the default set of built-in Keycloak REST endpoints.

To add a custom REST endpoint, you need to implement the RealmResourceProviderFactory and RealmResourceProvider interfaces. RealmResourceProvider has one important method:

Object getResource();

Use this method to return an object, which acts as a JAX-RS Resource. For more details, see the Javadoc and our examples. Your JAX-RS resource is only recognized by the server and registered as a valid endpoint if it includes the following configuration: - adding an empty file named beans.xml under META-INF - annotating the JAX-RS class with the annotation jakarta.ws.rs.ext.Provider. There is a very simple example in the example distribution in providers/rest and there is a more advanced example in providers/domain-extension, which shows how to add an authenticated REST endpoint and other functionalities like Adding your own SPI or Extending the datamodel with custom JPA entities.

For details on how to package and deploy a custom provider, refer to the Service Provider Interfaces chapter.

Add your own custom SPI

A custom SPI is especially useful with Custom REST endpoints. Use this procedure to add your own SPI

Procedure
  1. implement the interface org.keycloak.provider.Spi and define the ID of your SPI and the ProviderFactory and Provider classes. That looks like this:

    package org.keycloak.examples.domainextension.spi;
    
    import ...
    
    public class ExampleSpi implements Spi {
    
        @Override
        public boolean isInternal() {
            return false;
        }
    
        @Override
        public String getName() {
            return "example";
        }
    
        @Override
        public Class<? extends Provider> getProviderClass() {
            return ExampleService.class;
        }
    
        @Override
        @SuppressWarnings("rawtypes")
        public Class<? extends ProviderFactory> getProviderFactoryClass() {
            return ExampleServiceProviderFactory.class;
        }
    
    }
  2. Create the file META-INF/services/org.keycloak.provider.Spi and add the class of your SPI to it. For example:

    org.keycloak.examples.domainextension.spi.ExampleSpi
  3. Create the interfaces ExampleServiceProviderFactory, which extends from ProviderFactory and ExampleService, which extends from Provider. The ExampleService will usually contain the business methods you need for your use case. Note that the ExampleServiceProviderFactory instance is always scoped per application, however ExampleService is scoped per-request (or more accurately per KeycloakSession lifecycle).

  4. Finally you need to implement your providers in the same manner as described in the Service Provider Interfaces chapter.

For more details, take a look at the example distribution at providers/domain-extension, which shows an Example SPI similar to the one above.

Additional resources

Add custom JPA entities to the Keycloak data model

If the Keycloak data model does not exactly match your desired solution, or if you want to add some core functionality to Keycloak, or when you have your own REST endpoint, you might want to extend the Keycloak data model. We enable you to add your own JPA entities to the Keycloak JPA EntityManager .

To add your own JPA entities, you need to implement JpaEntityProviderFactory and JpaEntityProvider. The JpaEntityProvider allows you to return a list of your custom JPA entities and provide the location and id of the Liquibase changelog. An example implementation can look like this:

This is an unsupported API, which means you can use it but there is no guarantee that it will not be removed or changed without warning.
public class ExampleJpaEntityProvider implements JpaEntityProvider {

    // List of your JPA entities.
    @Override
    public List<Class<?>> getEntities() {
        return Collections.<Class<?>>singletonList(Company.class);
    }

    // This is used to return the location of the Liquibase changelog file.
    // You can return null if you don't want Liquibase to create and update the DB schema.
    @Override
    public String getChangelogLocation() {
            return "META-INF/example-changelog.xml";
    }

    // Helper method, which will be used internally by Liquibase.
    @Override
    public String getFactoryId() {
        return "sample";
    }

    ...
}

In the example above, we added a single JPA entity represented by class Company. In the code of your REST endpoint, you can then use something like this to retrieve EntityManager and call DB operations on it.

EntityManager em = session.getProvider(JpaConnectionProvider.class).getEntityManager();
Company myCompany = em.find(Company.class, "123");

The methods getChangelogLocation and getFactoryId are important to support automatic updating of your entities by Liquibase. Liquibase is a framework for updating the database schema, which Keycloak internally uses to create the DB schema and update the DB schema among versions. You may need to use it as well and create a changelog for your entities. Note that versioning of your own Liquibase changelog is independent of Keycloak versions. In other words, when you update to a new Keycloak version, you are not forced to update your schema at the same time. And vice versa, you can update your schema even without updating the Keycloak version. The Liquibase update is always done at the server startup, so to trigger a DB update of your schema, you just need to add the new changeset to your Liquibase changelog file (in the example above it’s the file META-INF/example-changelog.xml which must be packed in same JAR as the JPA entities and ExampleJpaEntityProvider) and then restart server. The DB schema will be automatically updated at startup.

For more details, take a look at the example distribution at example providers/domain-extension, which shows the ExampleJpaEntityProvider and example-changelog.xml described above.

Don’t forget to always back up your database before doing any changes in the Liquibase changelog and triggering a DB update.

Authentication SPI

Keycloak includes a range of different authentication mechanisms: kerberos, password, otp and others. These mechanisms may not meet all of your requirements and you may want to plug in your own custom ones. Keycloak provides an authentication SPI that you can use to write new plugins. The Admin Console supports applying, ordering, and configuring these new mechanisms.

Keycloak also supports a simple registration form. Different aspects of this form can be enabled and disabled for example Recaptcha support can be turned off and on. The same authentication SPI can be used to add another page to the registration flow or reimplement it entirely. There’s also an additional fine-grained SPI you can use to add specific validations and user extensions to the built-in registration form.

A required action in Keycloak is an action that a user has to perform after he authenticates. After the action is performed successfully, the user doesn’t have to perform the action again. Keycloak comes with some built in required actions like "reset password". This action forces the user to change their password after they have logged in. You can write and plug in your own required actions.

If your authenticator or required action implementation is using some user attributes as the metadata attributes for linking/establishing the user identity, then please make sure that users are not able to edit the attributes and the corresponding attributes are read-only. See the details in the Threat model mitigation chapter.

Terms

To first learn about the Authentication SPI, let’s go over some of the terms used to describe it.

Authentication Flow

A flow is a container for all authentications that must happen during login or registration. If you go to the Admin Console authentication page, you can view all the defined flows in the system and what authenticators they are made up of. Flows can contain other flows. You can also bind a new different flow for browser login, direct grant access, and registration.

Authenticator

An authenticator is a pluggable component that hold the logic for performing the authentication or action within a flow. It is usually a singleton.

Execution

An execution is an object that binds the authenticator to the flow and the authenticator to the configuration of the authenticator. Flows contain execution entries.

Execution Requirement

Each execution defines how an authenticator behaves in a flow. The requirement defines whether the authenticator is enabled, disabled, conditional, required, or an alternative. An alternative requirement means that the authenticator is enough to validate the flow it’s in, but isn’t necessary. For example, in the built-in browser flow, cookie authentication, the Identity Provider Redirector, and the set of all authenticators in the forms subflow are all alternative. As they are executed in a sequential top-to-bottom order, if one of them is successful, the flow is successful, and any following execution in the flow (or sub-flow) is not evaluated.

Authenticator Config

This object defines the configuration for the Authenticator for a specific execution within an authentication flow. Each execution can have a different config.

Required Action

After authentication completes, the user might have one or more one-time actions he must complete before he is allowed to login. The user might be required to set up an OTP token generator or reset an expired password or even accept a Terms and Conditions document.

Algorithm overview

Let’s talk about how this all works for browser login. Let’s assume the following flows, executions and sub flows.

Cookie - ALTERNATIVE
Kerberos - ALTERNATIVE
Forms subflow - ALTERNATIVE
           Username/Password Form - REQUIRED
           Conditional OTP subflow - CONDITIONAL
                      Condition - User Configured - REQUIRED
                      OTP Form - REQUIRED

In the top level of the form we have 3 executions of which all are alternatively required. This means that if any of these are successful, then the others do not have to execute. The Username/Password form is not executed if there is an SSO Cookie set or a successful Kerberos login. Let’s walk through the steps from when a client first redirects to keycloak to authenticate the user.

  1. The OpenID Connect or SAML protocol provider unpacks relevant data, verifies the client and any signatures. It creates an AuthenticationSessionModel. It looks up what the browser flow should be, then starts executing the flow.

  2. The flow looks at the cookie execution and sees that it is an alternative. It loads the cookie provider. It checks to see if the cookie provider requires that a user already be associated with the authentication session. Cookie provider does not require a user. If it did, the flow would abort and the user would see an error screen. Cookie provider then executes. Its purpose is to see if there is an SSO cookie set. If there is one set, it is validated and the UserSessionModel is verified and associated with the AuthenticationSessionModel. The Cookie provider returns a success() status if the SSO cookie exists and is validated. Since the cookie provider returned success and each execution at this level of the flow is ALTERNATIVE, no other execution is executed and this results in a successful login. If there is no SSO cookie, the cookie provider returns with a status of attempted(). This means there was no error condition, but no success either. The provider tried, but the request just wasn’t set up to handle this authenticator.

  3. Next the flow looks at the Kerberos execution. This is also an alternative. The kerberos provider also does not require a user to be already set up and associated with the AuthenticationSessionModel so this provider is executed. Kerberos uses the SPNEGO browser protocol. This requires a series of challenge/responses between the server and client exchanging negotiation headers. The kerberos provider does not see any negotiate header, so it assumes that this is the first interaction between the server and client. It therefore creates an HTTP challenge response to the client and sets a forceChallenge() status. A forceChallenge() means that this HTTP response cannot be ignored by the flow and must be returned to the client. If instead the provider returned a challenge() status, the flow would hold the challenge response until all other alternatives are attempted. So, in this initial phase, the flow would stop and the challenge response would be sent back to the browser. If the browser then responds with a successful negotiate header, the provider associates the user with the AuthenticationSession and the flow ends because the rest of the executions on this level of the flow are all alternatives. Otherwise, again, the kerberos provider sets an attempted() status and the flow continues.

  4. The next execution is a subflow called Forms. The executions for this subflow are loaded and the same processing logic occurs.

  5. The first execution in the Forms subflow is the UsernamePassword provider. This provider also does not require for a user to already be associated with the flow. This provider creates a challenge HTTP response and sets its status to challenge(). This execution is required, so the flow honors this challenge and sends the HTTP response back to the browser. This response is a rendering of the Username/Password HTML page. The user enters in their username and password and clicks submit. This HTTP request is directed to the UsernamePassword provider. If the user entered an invalid username or password, a new challenge response is created and a status of failureChallenge() is set for this execution. A failureChallenge() means that there is a challenge, but that the flow should log this as an error in the error log. This error log can be used to lock accounts or IP Addresses that have had too many login failures. If the username and password is valid, the provider associated the UserModel with the AuthenticationSessionModel and returns a status of success().

  6. The next execution is a subflow called Conditional OTP. The executions for this subflow are loaded and the same processing logic occurs. Its Requirement is Conditional. This means that the flow will first evaluate all conditional executors that it contains. Conditional executors are authenticators that implement ConditionalAuthenticator, and must implement the method boolean matchCondition(AuthenticationFlowContext context). A conditional subflow will call the matchCondition method of all conditional executions it contains, and if all of them evaluate to true, it will act as if it was a required subflow. If not, it will act as if it was a disabled subflow. Conditional authenticators are only used for this purpose, and are not used as authenticators. This means that even if the conditional authenticator evaluates to "true", then this will not mark a flow or subflow as successful. For example, a flow containing only a Conditional subflow with only a conditional authenticator will never allow a user to log in.

  7. The first execution of the Conditional OTP subflow is the Condition - User Configured. This provider requires that a user has been associated with the flow. This requirement is satisfied because the UsernamePassword provider already associated the user with the flow. This provider’s matchCondition method will evaluate the configuredFor method for all other Authenticators in its current subflow. If the subflow contains executors with their Requirement set to required, then the matchCondition method will only evaluate to true if all the required authenticators' configuredFor method evaluate to true. Otherwise, the matchCondition method will evaluate to true if any alternative authenticator evaluates to true.

  8. The next execution is the OTP Form. This provider also requires that a user has been associated with the flow. This requirement is satisfied because the UsernamePassword provider already associated the user with the flow. Since a user is required for this provider, the provider is also asked if the user is configured to use this provider. If user is not configured, then the flow will then set up a required action that the user must perform after authentication is complete. For OTP, this means the OTP setup page. If the user is configured, he will be asked to enter his otp code. In our scenario, because of the conditional sub-flow, the user will never see the OTP login page, unless the Conditional OTP subflow is set to Required.

  9. After the flow is complete, the authentication processor creates a UserSessionModel and associates it with the AuthenticationSessionModel. It then checks to see if the user is required to complete any required actions before logging in.

  10. First, each required action’s evaluateTriggers() method is called. This allows the required action provider to figure out if there is some state that might trigger the action to be fired. For example, if your realm has a password expiration policy, it might be triggered by this method.

  11. Each required action associated with the user that has its requiredActionChallenge() method called. Here the provider sets up an HTTP response which renders the page for the required action. This is done by setting a challenge status.

  12. If the required action is ultimately successful, then the required action is removed from the user’s required actions list.

  13. After all required actions have been resolved, the user is finally logged in.

Authenticator SPI walk through

In this section, we’ll take a look at the Authenticator interface. For this, we are going to implement an authenticator that requires that a user enter in the answer to a secret question like "What is your mother’s maiden name?". This example is fully implemented and contained in the examples/providers/authenticator directory of the demo distribution of Keycloak.

To create an authenticator, you must at minimum implement the org.keycloak.authentication.AuthenticatorFactory and Authenticator interfaces. The Authenticator interface defines the logic. The AuthenticatorFactory is responsible for creating instances of an Authenticator. They both extend a more generic Provider and ProviderFactory set of interfaces that other Keycloak components like User Federation do.

Some authenticators, like the CookieAuthenticator don’t rely on a Credential that the user has or knows to authenticate the user. However, some authenticators, such as the PasswordForm authenticator or the OTPFormAuthenticator rely on the user inputting some information and verifying that information against some information in the database. For the PasswordForm for example, the authenticator will verify the hash of the password against a hash stored in the database, while the OTPFormAuthenticator will verify the OTP received against the one generated from the shared secret stored in the database.

These types of authenticators are called CredentialValidators, and will require you to implement a few more classes:

  • A class that extends org.keycloak.credential.CredentialModel, and that can generate the correct format of the credential in the database

  • A class implementing the org.keycloak.credential.CredentialProvider and interface, and a class implementing its CredentialProviderFactory factory interface.

The SecretQuestionAuthenticator we’ll see in this walk through is a CredentialValidator, so we’ll see how to implement all these classes.

Packaging classes and deployment

You will package your classes within a single jar. This jar must contain a file named org.keycloak.authentication.AuthenticatorFactory and must be contained in the META-INF/services/ directory of your jar. This file must list the fully qualified class name of each AuthenticatorFactory implementation you have in the jar. For example:

org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory
org.keycloak.examples.authenticator.AnotherProviderFactory

This services/ file is used by Keycloak to scan the providers it has to load into the system.

To deploy this jar, just copy it to the providers directory.

Extending the CredentialModel class

In Keycloak, credentials are stored in the database in the Credentials table. It has the following structure:

-----------------------------
| ID                        |
-----------------------------
| user_ID                   |
-----------------------------
| credential_type           |
-----------------------------
| created_date              |
-----------------------------
| user_label                |
-----------------------------
| secret_data               |
-----------------------------
| credential_data           |
-----------------------------
| priority                  |
-----------------------------

Where:

  • ID is the primary key of the credential.

  • user_ID is the foreign key linking the credential to a user.

  • credential_type is a string set during the creation that must reference an existing credential type.

  • created_date is the creation timestamp (in long format) of the credential.

  • user_label is the editable name of the credential by the user

  • secret_data contains a static json with the information that cannot be transmitted outside of Keycloak

  • credential_data contains a json with the static information of the credential that can be shared in the Admin Console or via the REST API.

  • priority defines how "preferred" a credential is for a user, to determine which credential to present when a user has multiple choices.

As the secret_data and credential_data fields are designed to contain json, it is up to you to determine how to structure, read and write into these fields, allowing you a lot of flexibility.

For this example, we are going to use a very simple credential data, containing only the question asked to the user:

{
  "question":"aQuestion"
}

with an equally simple secret data, containing only the secret answer:

{
  "answer":"anAnswer"
}

Here the answer will be kept in plain text in the database for the sake of simplicity, but it would also be possible to have a salted hash for the answer, as is the case for passwords in Keycloak. In this case, the secret data would also have to contain a field for the salt, and the credential data information about the algorithm such as the type of algorithm used and the number of iterations used. For more details you can consult the implementation of the org.keycloak.models.credential.PasswordCredentialModel class.

In our case we create the class SecretQuestionCredentialModel:

public class SecretQuestionCredentialModel extends CredentialModel {
    public static final String TYPE = "SECRET_QUESTION";

    private final SecretQuestionCredentialData credentialData;
    private final SecretQuestionSecretData secretData;

Where TYPE is the credential_type we write in the database. For consistency, we make sure that this String is always the one referenced when getting the type for this credential. The classes SecretQuestionCredentialData and SecretQuestionSecretData are used to marshal and unmarshal the json:

public class SecretQuestionCredentialData {

    private final String question;

    @JsonCreator
    public SecretQuestionCredentialData(@JsonProperty("question") String question) {
        this.question = question;
    }

    public String getQuestion() {
        return question;
    }
}
public class SecretQuestionSecretData {

     private final String answer;

    @JsonCreator
     public SecretQuestionSecretData(@JsonProperty("answer") String answer) {
         this.answer = answer;
     }

    public String getAnswer() {
        return answer;
    }
}

To be fully usable, the SecretQuestionCredentialModel objects must both contain the raw json data from its parent class, and the unmarshalled objects in its own attributes. This leads us to create a method which reads from a simple CredentialModel, such as is created when reading from the database, to make a SecretQuestionCredentialModel:

private SecretQuestionCredentialModel(SecretQuestionCredentialData credentialData, SecretQuestionSecretData secretData) {
    this.credentialData = credentialData;
    this.secretData = secretData;
}

public static SecretQuestionCredentialModel createFromCredentialModel(CredentialModel credentialModel){
    try {
        SecretQuestionCredentialData credentialData = JsonSerialization.readValue(credentialModel.getCredentialData(), SecretQuestionCredentialData.class);
        SecretQuestionSecretData secretData = JsonSerialization.readValue(credentialModel.getSecretData(), SecretQuestionSecretData.class);

        SecretQuestionCredentialModel secretQuestionCredentialModel = new SecretQuestionCredentialModel(credentialData, secretData);
        secretQuestionCredentialModel.setUserLabel(credentialModel.getUserLabel());
        secretQuestionCredentialModel.setCreatedDate(credentialModel.getCreatedDate());
        secretQuestionCredentialModel.setType(TYPE);
        secretQuestionCredentialModel.setId(credentialModel.getId());
        secretQuestionCredentialModel.setSecretData(credentialModel.getSecretData());
        secretQuestionCredentialModel.setCredentialData(credentialModel.getCredentialData());
        return secretQuestionCredentialModel;
    } catch (IOException e){
        throw new RuntimeException(e);
    }
}

And a method to create a SecretQuestionCredentialModel from the question and answer:

private SecretQuestionCredentialModel(String question, String answer) {
    credentialData = new SecretQuestionCredentialData(question);
    secretData = new SecretQuestionSecretData(answer);
}

public static SecretQuestionCredentialModel createSecretQuestion(String question, String answer) {
    SecretQuestionCredentialModel credentialModel = new SecretQuestionCredentialModel(question, answer);
    credentialModel.fillCredentialModelFields();
    return credentialModel;
}

private void fillCredentialModelFields(){
    try {
        setCredentialData(JsonSerialization.writeValueAsString(credentialData));
        setSecretData(JsonSerialization.writeValueAsString(secretData));
        setType(TYPE);
        setCreatedDate(Time.currentTimeMillis());
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

Implementing a CredentialProvider

As with all Providers, to allow Keycloak to generate the CredentialProvider, we require a CredentialProviderFactory. For this requirement we create the SecretQuestionCredentialProviderFactory, whose create method will be called when a SecretQuestionCredentialProvider is asked for:

public class SecretQuestionCredentialProviderFactory implements CredentialProviderFactory<SecretQuestionCredentialProvider> {

    public static final String PROVIDER_ID =  "secret-question";

    @Override
    public String getId() {
        return PROVIDER_ID;
    }

    @Override
    public CredentialProvider create(KeycloakSession session) {
        return new SecretQuestionCredentialProvider(session);
    }
}

The CredentialProvider interface takes a generic parameter that extends a CredentialModel. In our case we to use the SecretQuestionCredentialModel we created:

public class SecretQuestionCredentialProvider implements CredentialProvider<SecretQuestionCredentialModel>, CredentialInputValidator {
    private static final Logger logger = Logger.getLogger(SecretQuestionCredentialProvider.class);

    protected KeycloakSession session;

    public SecretQuestionCredentialProvider(KeycloakSession session) {
        this.session = session;
    }

We also want to implement the CredentialInputValidator interface, as this allows Keycloak to know that this provider can also be used to validate a credential for an Authenticator. For the CredentialProvider interface, the first method that needs to be implemented is the getType() method. This will simply return the `SecretQuestionCredentialModel’s TYPE String:

@Override
public String getType() {
    return SecretQuestionCredentialModel.TYPE;
}

The second method is to create a SecretQuestionCredentialModel from a CredentialModel. For this method we simply call the existing static method from SecretQuestionCredentialModel:

@Override
public SecretQuestionCredentialModel getCredentialFromModel(CredentialModel model) {
    return SecretQuestionCredentialModel.createFromCredentialModel(model);
}

Finally, we have the methods to create a credential and delete a credential. These methods call the UserModel’s credential manager, which is responsible for knowing where to read or write the credential, for example local storage or federated storage.

@Override
public CredentialModel createCredential(RealmModel realm, UserModel user, SecretQuestionCredentialModel credentialModel) {
    if (credentialModel.getCreatedDate() == null) {
        credentialModel.setCreatedDate(Time.currentTimeMillis());
    }
    return user.credentialManager().createStoredCredential(credentialModel);
}

@Override
public boolean deleteCredential(RealmModel realm, UserModel user, String credentialId) {
    return user.credentialManager().removeStoredCredentialById(credentialId);
}

For the CredentialInputValidator, the main method to implement is the isValid, which tests whether a credential is valid for a given user in a given realm. This is the method that is called by the Authenticator when it seeks to validate the user’s input. Here we simply need to check that the input String is the one recorded in the Credential:

@Override
public boolean isValid(RealmModel realm, UserModel user, CredentialInput input) {
    if (!(input instanceof UserCredentialModel)) {
        logger.debug("Expected instance of UserCredentialModel for CredentialInput");
        return false;
    }
    if (!input.getType().equals(getType())) {
        return false;
    }
    String challengeResponse = input.getChallengeResponse();
    if (challengeResponse == null) {
        return false;
    }
    CredentialModel credentialModel = getCredentialStore().getStoredCredentialById(realm, user, input.getCredentialId());
    SecretQuestionCredentialModel sqcm = getCredentialFromModel(credentialModel);
    return sqcm.getSecretQuestionSecretData().getAnswer().equals(challengeResponse);
}

The other two methods to implement are a test if the CredentialProvider supports the given credential type and a test to check if the credential type is configured for a given user. For our case, the latter test simply means checking if the user has a credential of the SECRET_QUESTION type:

@Override
public boolean supportsCredentialType(String credentialType) {
    return getType().equals(credentialType);
}

@Override
public boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType) {
    if (!supportsCredentialType(credentialType)) return false;
    return !getCredentialStore().getStoredCredentialsByType(realm, user, credentialType).isEmpty();
}

Implementing an authenticator

When implementing an authenticator that uses Credentials to authenticate a user, you should have the authenticator implement the CredentialValidator interface. This interfaces takes a class extending a CredentialProvider as a parameter, and will allow Keycloak to directly call the methods from the CredentialProvider. The only method that needs to be implemented is getCredentialProvider method, which in our example allows the SecretQuestionAuthenticator to retrieve the SecretQuestionCredentialProvider:

public SecretQuestionCredentialProvider getCredentialProvider(KeycloakSession session) {
    return (SecretQuestionCredentialProvider)session.getProvider(CredentialProvider.class, SecretQuestionCredentialProviderFactory.PROVIDER_ID);
}

When implementing the Authenticator interface, the first method that needs to be implemented is the requiresUser() method. For our example, this method must return true as we need to validate the secret question associated with the user. A provider like kerberos would return false from this method as it can resolve a user from the negotiate header. This example, however, is validating a specific credential of a specific user.

The next method to implement is the configuredFor() method. This method is responsible for determining if the user is configured for this particular authenticator. In our case, we can just call the method implemented in the SecretQuestionCredentialProvider

@Override
public boolean configuredFor(KeycloakSession session, RealmModel realm, UserModel user) {
    return getCredentialProvider(session).isConfiguredFor(realm, user, getType(session));
}

The next method to implement on the Authenticator is setRequiredActions(). If configuredFor() returns false and our example authenticator is required within the flow, this method will be called, but only if the associated AuthenticatorFactory’s isUserSetupAllowed method returns true. The setRequiredActions() method is responsible for registering any required actions that must be performed by the user. In our example, we need to register a required action that will force the user to set up the answer to the secret question. We will implement this required action provider later in this chapter. Here is the implementation of the setRequiredActions() method.

    @Override
    public void setRequiredActions(KeycloakSession session, RealmModel realm, UserModel user) {
        user.addRequiredAction("SECRET_QUESTION_CONFIG");
    }

Now we are getting into the meat of the Authenticator implementation. The next method to implement is authenticate(). This is the initial method the flow invokes when the execution is first visited. What we want is that if a user has answered the secret question already on their browser’s machine, then the user doesn’t have to answer the question again, making that machine "trusted". The authenticate() method isn’t responsible for processing the secret question form. Its sole purpose is to render the page or to continue the flow.

@Override
public void authenticate(AuthenticationFlowContext context) {
    if (hasCookie(context)) {
        context.success();
        return;
    }
    Response challenge = context.form()
            .createForm("secret-question.ftl");
    context.challenge(challenge);
}

protected boolean hasCookie(AuthenticationFlowContext context) {
    Cookie cookie = context.getHttpRequest().getHttpHeaders().getCookies().get("SECRET_QUESTION_ANSWERED");
    boolean result = cookie != null;
    if (result) {
        System.out.println("Bypassing secret question because cookie is set");
    }
    return result;
}

The hasCookie() method checks to see if there is already a cookie set on the browser which indicates that the secret question has already been answered. If that returns true, we just mark this execution’s status as SUCCESS using the AuthenticationFlowContext.success() method and returning from the authentication() method.

If the hasCookie() method returns false, we must return a response that renders the secret question HTML form. AuthenticationFlowContext has a form() method that initializes a Freemarker page builder with appropriate base information needed to build the form. This page builder is called org.keycloak.login.LoginFormsProvider. The LoginFormsProvider.createForm() method loads a Freemarker template file from your login theme. Additionally you can call the LoginFormsProvider.setAttribute() method if you want to pass additional information to the Freemarker template. We’ll go over this later.

Calling LoginFormsProvider.createForm() returns a JAX-RS Response object. We then call AuthenticationFlowContext.challenge() passing in this response. This sets the status of the execution as CHALLENGE and if the execution is Required, this JAX-RS Response object will be sent to the browser.

So, the HTML page asking for the answer to a secret question is displayed to the user and the user enters in the answer and clicks submit. The action URL of the HTML form will send an HTTP request to the flow. The flow will end up invoking the action() method of our Authenticator implementation.

@Override
public void action(AuthenticationFlowContext context) {
    boolean validated = validateAnswer(context);
    if (!validated) {
        Response challenge =  context.form()
                .setError("badSecret")
                .createForm("secret-question.ftl");
        context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS, challenge);
        return;
    }
    setCookie(context);
    context.success();
}

If the answer is not valid, we rebuild the HTML Form with an additional error message. We then call AuthenticationFlowContext.failureChallenge() passing in the reason for the value and the JAX-RS response. failureChallenge() works the same as challenge(), but it also records the failure so it can be analyzed by any attack detection service.

If validation is successful, then we set a cookie to remember that the secret question has been answered and we call AuthenticationFlowContext.success().

The validation itself gets the data that was received from the form, and calls the isValid method from the SecretQuestionCredentialProvider. You’ll notice that there’s a section of the code concerning getting the credential Id. This is because if Keycloak is configured to allow multiple types of alternative authenticators, or if the user could record multiple credentials of the SECRET_QUESTION type (for example if we allowed to choose from several questions, and we allowed the user to have answers for more than one of those questions), then Keycloak needs to know which credential is being used to log the user. In case there is more than one credential, Keycloak allows the user to choose during the login which credential is being used, and the information is transmitted by the form to the Authenticator. In case the form doesn’t present this information, credential id used is given by the CredentialProvider’s default getDefaultCredential method, which will return the "most preferred" credential of the correct type of the user,

protected boolean validateAnswer(AuthenticationFlowContext context) {
    MultivaluedMap<String, String> formData = context.getHttpRequest().getDecodedFormParameters();
    String secret = formData.getFirst("secret_answer");
    String credentialId = formData.getFirst("credentialId");
    if (credentialId == null || credentialId.isEmpty()) {
        credentialId = getCredentialProvider(context.getSession())
                .getDefaultCredential(context.getSession(), context.getRealm(), context.getUser()).getId();
    }

    UserCredentialModel input = new UserCredentialModel(credentialId, getType(context.getSession()), secret);
    return getCredentialProvider(context.getSession()).isValid(context.getRealm(), context.getUser(), input);
}

Next method is the setCookie(). This is an example of providing configuration for the Authenticator. In this case we want the max age of the cookie to be configurable.

protected void setCookie(AuthenticationFlowContext context) {
    AuthenticatorConfigModel config = context.getAuthenticatorConfig();
    int maxCookieAge = 60 * 60 * 24 * 30; // 30 days
    if (config != null) {
        maxCookieAge = Integer.valueOf(config.getConfig().get("cookie.max.age"));

    }
    URI uri = context.getUriInfo().getBaseUriBuilder().path("realms").path(context.getRealm().getName()).build();
    addCookie(context, "SECRET_QUESTION_ANSWERED", "true",
            uri.getRawPath(),
            null, null,
            maxCookieAge,
            false, true);
}

We obtain an AuthenticatorConfigModel from the AuthenticationFlowContext.getAuthenticatorConfig() method. If configuration exists we pull the max age config out of it. We will see how we can define what should be configured when we talk about the AuthenticatorFactory implementation. The config values can be defined within the Admin Console if you set up config definitions in your AuthenticatorFactory implementation.

@Override
    public CredentialTypeMetadata getCredentialTypeMetadata(CredentialTypeMetadataContext metadataContext) {
        return CredentialTypeMetadata.builder()
                .type(getType())
                .category(CredentialTypeMetadata.Category.TWO_FACTOR)
                .displayName(SecretQuestionCredentialProviderFactory.PROVIDER_ID)
                .helpText("secret-question-text")
                .createAction(SecretQuestionAuthenticatorFactory.PROVIDER_ID)
                .removeable(false)
                .build(session);
    }

The last method to implement in the SecretQuestionCredentialProvider class is getCredentialTypeMetadata(CredentialTypeMetadataContext metadataContext), which is an abstract method of the CredentialProvider interface. Each Credential provider has to provide and implement this method. The method returns an instance of CredentialTypeMetadata, which should at least include type and category of authenticator, displayName and removable item. In this example, the builder takes type of authenticator from method getType(), category is Two Factor (the authenticator can be used as second factor of authentication) and removable, which is set up to false (user can’t remove some previously registered credentials).

Other items of builder are helpText (will be shown to the user on various screens), createAction (the providerID of the required action, which can be used by the user to create new credential) or updateAction (same as createAction, but instead of creating the new credential, it will update the credential).

Implementing an AuthenticatorFactory

The next step in this process is to implement an AuthenticatorFactory. This factory is responsible for instantiating an Authenticator. It also provides deployment and configuration metadata about the Authenticator.

The getId() method is just the unique name of the component. The create() method is called by the runtime to allocate and process the Authenticator.

public class SecretQuestionAuthenticatorFactory implements AuthenticatorFactory, ConfigurableAuthenticatorFactory {

    public static final String PROVIDER_ID = "secret-question-authenticator";
    private static final SecretQuestionAuthenticator SINGLETON = new SecretQuestionAuthenticator();

    @Override
    public String getId() {
        return PROVIDER_ID;
    }

    @Override
    public Authenticator create(KeycloakSession session) {
        return SINGLETON;
    }

The next thing the factory is responsible for is to specify the allowed requirement switches. While there are four different requirement types: ALTERNATIVE, REQUIRED, CONDITIONAL, DISABLED, AuthenticatorFactory implementations can limit which requirement options are shown in the Admin Console when defining a flow. CONDITIONAL should only always be used for subflows, and unless there’s a good reason for doing otherwise, the requirement on an authenticator should be REQUIRED, ALTERNATIVE and DISABLED:

    private static AuthenticationExecutionModel.Requirement[] REQUIREMENT_CHOICES = {
            AuthenticationExecutionModel.Requirement.REQUIRED,
            AuthenticationExecutionModel.Requirement.ALTERNATIVE,
            AuthenticationExecutionModel.Requirement.DISABLED
    };
    @Override
    public AuthenticationExecutionModel.Requirement[] getRequirementChoices() {
        return REQUIREMENT_CHOICES;
    }

The AuthenticatorFactory.isUserSetupAllowed() is a flag that tells the flow manager whether or not Authenticator.setRequiredActions() method will be called. If an Authenticator is not configured for a user, the flow manager checks isUserSetupAllowed(). If it is false, then the flow aborts with an error. If it returns true, then the flow manager will invoke Authenticator.setRequiredActions().

    @Override
    public boolean isUserSetupAllowed() {
        return true;
    }

The next few methods define how the Authenticator can be configured. The isConfigurable() method is a flag which specifies to the Admin Console on whether the Authenticator can be configured within a flow. The getConfigProperties() method returns a list of ProviderConfigProperty objects. These objects define a specific configuration attribute.

    @Override
    public List<ProviderConfigProperty> getConfigProperties() {
        return configProperties;
    }

    private static final List<ProviderConfigProperty> configProperties = new ArrayList<ProviderConfigProperty>();

    static {
        ProviderConfigProperty property;
        property = new ProviderConfigProperty();
        property.setName("cookie.max.age");
        property.setLabel("Cookie Max Age");
        property.setType(ProviderConfigProperty.STRING_TYPE);
        property.setHelpText("Max age in seconds of the SECRET_QUESTION_COOKIE.");
        configProperties.add(property);
    }

Each ProviderConfigProperty defines the name of the config property. This is the key used in the config map stored in AuthenticatorConfigModel. The label defines how the config option will be displayed in the Admin Console. The type defines if it is a String, Boolean, or other type. The Admin Console will display different UI inputs depending on the type. The help text is what will be shown in the tooltip for the config attribute in the Admin Console. Read the javadoc of ProviderConfigProperty for more detail.

The rest of the methods are for the Admin Console. getHelpText() is the tooltip text that will be shown when you are picking the Authenticator you want to bind to an execution. getDisplayType() is the text that will be shown in the Admin Console when listing the Authenticator. getReferenceCategory() is just a category the Authenticator belongs to.

Adding an authenticator form

Keycloak comes with a Freemarker theme and template engine. The createForm() method you called within authenticate() of your Authenticator class, builds an HTML page from a file within your login theme: secret-question.ftl. This file should be added to the theme-resources/templates in your JAR, see Theme Resource Provider for more details.

Let’s take a bigger look at secret-question.ftl Here’s a small code snippet:

        <form id="kc-totp-login-form" class="${properties.kcFormClass!}" action="${url.loginAction}" method="post">
            <div class="${properties.kcFormGroupClass!}">
                <div class="${properties.kcLabelWrapperClass!}">
                    <label for="totp" class="${properties.kcLabelClass!}">${msg("loginSecretQuestion")}</label>
                </div>

                <div class="${properties.kcInputWrapperClass!}">
                    <input id="totp" name="secret_answer" type="text" class="${properties.kcInputClass!}" />
                </div>
            </div>
        </form>

Any piece of text enclosed in ${} corresponds to an attribute or template function. If you see the form’s action, you see it points to ${url.loginAction}. This value is automatically generated when you invoke the AuthenticationFlowContext.form() method. You can also obtain this value by calling the AuthenticationFlowContext.getActionURL() method in Java code.

You’ll also see ${properties.someValue}. These correspond to properties defined in your theme.properties file of our theme. ${msg("someValue")} corresponds to the internationalized message bundles (.properties files) included with the login theme messages/ directory. If you’re just using english, you can just add the value of the loginSecretQuestion. This should be the question you want to ask the user.

When you call AuthenticationFlowContext.form() this gives you a LoginFormsProvider instance. If you called, LoginFormsProvider.setAttribute("foo", "bar"), the value of "foo" would be available for reference in your form as ${foo}. The value of an attribute can be any Java bean as well.

If you look at the top of the file, you’ll see that we are importing a template:

<#import "select.ftl" as layout>

Importing this template, instead of the standard template.ftl allows Keycloak to display a dropdown box that allows the user to select a different credential or execution.

Adding an authenticator to a flow

Adding an Authenticator to a flow must be done in the Admin Console. If you go to the Authentication menu item and go to the Flow tab, you will be able to view the currently defined flows. You cannot modify built in flows, so, to add the Authenticator we’ve created you have to copy an existing flow or create your own. Our hope is that the user interface is sufficiently clear so that you can determine how to create a flow and add the Authenticator. For more details, see the Authentication Flows chapter in Server Administration Guide .

After you’ve created your flow, you have to bind it to the login action you want to bind it to. If you go to the Authentication menu and go to the Bindings tab you will see options to bind a flow to the browser, registration, or direct grant flow.

Required action walkthrough

In this section we will discuss how to define a required action. In the Authenticator section you may have wondered, "How will we get the user’s answer to the secret question entered into the system?". As we showed in the example, if the answer is not set up, a required action will be triggered. This section discusses how to implement the required action for the Secret Question Authenticator.

Packaging classes and deployment

You will package your classes within a single jar. This jar does not have to be separate from other provider classes but it must contain a file named org.keycloak.authentication.RequiredActionFactory and must be contained in the META-INF/services/ directory of your jar. This file must list the fully qualified classname of each RequiredActionFactory implementation you have in the jar. For example:

org.keycloak.examples.authenticator.SecretQuestionRequiredActionFactory

This services/ file is used by Keycloak to scan the providers it has to load into the system.

To deploy this jar, copy it to the providers/ directory, then run bin/kc.[sh|bat] build.

Implement the RequiredActionProvider

Required actions must first implement the RequiredActionProvider interface. The RequiredActionProvider.requiredActionChallenge() is the initial call by the flow manager into the required action. This method is responsible for rendering the HTML form that will drive the required action.

    @Override
    public void requiredActionChallenge(RequiredActionContext context) {
        Response challenge = context.form().createForm("secret_question_config.ftl");
        context.challenge(challenge);

    }

You see that RequiredActionContext has similar methods to AuthenticationFlowContext. The form() method allows you to render the page from a Freemarker template. The action URL is preset by the call to this form() method. You just need to reference it within your HTML form. I’ll show you this later.

The challenge() method notifies the flow manager that a required action must be executed.

The next method is responsible for processing input from the HTML form of the required action. The action URL of the form will be routed to the RequiredActionProvider.processAction() method

    @Override
    public void processAction(RequiredActionContext context) {
        String answer = (context.getHttpRequest().getDecodedFormParameters().getFirst("answer"));
        UserCredentialValueModel model = new UserCredentialValueModel();
        model.setValue(answer);
        model.setType(SecretQuestionAuthenticator.CREDENTIAL_TYPE);
        context.getUser().updateCredentialDirectly(model);
        context.success();
    }

The answer is pulled out of the form post. A UserCredentialValueModel is created and the type and value of the credential are set. Then UserModel.updateCredentialDirectly() is invoked. Finally, RequiredActionContext.success() notifies the container that the required action was successful.

Implement the RequiredActionFactory

This class is really simple. It is just responsible for creating the required action provider instance.

public class SecretQuestionRequiredActionFactory implements RequiredActionFactory {

    private static final SecretQuestionRequiredAction SINGLETON = new SecretQuestionRequiredAction();

    @Override
    public RequiredActionProvider create(KeycloakSession session) {
        return SINGLETON;
    }


    @Override
    public String getId() {
        return SecretQuestionRequiredAction.PROVIDER_ID;
    }

    @Override
    public String getDisplayText() {
        return "Secret Question";
    }

The getDisplayText() method is just for the Admin Console when it wants to display a friendly name for the required action.

Enable required action

The final thing you have to do is go into the Admin Console. Click on the Authentication left menu. Click on the Required Actions tab. Click on the Register button and choose your new Required Action. Your new required action should now be displayed and enabled in the required actions list.

Modifying or extending the registration form

It is entirely possible for you to implement your own flow with a set of Authenticators to totally change how registration is done in Keycloak. But what you’ll usually want to do is just add a bit of validation to the out-of-the-box registration page. An additional SPI was created to be able to do this. It basically allows you to add validation of form elements on the page as well as to initialize UserModel attributes and data after the user has been registered. We’ll look at both the implementation of the user profile registration processing as well as the registration Google Recaptcha plugin.

Implementation FormAction interface

The core interface you have to implement is the FormAction interface. A FormAction is responsible for rendering and processing a portion of the page. Rendering is done in the buildPage() method, validation is done in the validate() method, post validation operations are done in success(). Let’s first take a look at buildPage() method of the Recaptcha plugin.

    @Override
    public void buildPage(FormContext context, LoginFormsProvider form) {
        AuthenticatorConfigModel captchaConfig = context.getAuthenticatorConfig();
        if (captchaConfig == null || captchaConfig.getConfig() == null
                || captchaConfig.getConfig().get(SITE_KEY) == null
                || captchaConfig.getConfig().get(SITE_SECRET) == null
                ) {
            form.addError(new FormMessage(null, Messages.RECAPTCHA_NOT_CONFIGURED));
            return;
        }
        String siteKey = captchaConfig.getConfig().get(SITE_KEY);
        form.setAttribute("recaptchaRequired", true);
        form.setAttribute("recaptchaSiteKey", siteKey);
        form.addScript("https://www.google.com/recaptcha/api.js");
    }

The Recaptcha buildPage() method is a callback by the form flow to help render the page. It receives a form parameter which is a LoginFormsProvider. You can add additional attributes to the form provider so that they can be displayed in the HTML page generated by the registration Freemarker template.

The code above is from the registration recaptcha plugin. Recaptcha requires some specific settings that must be obtained from configuration. FormActions are configured in the exact same as Authenticators are. In this example, we pull the Google Recaptcha site key from configuration and add it as an attribute to the form provider. Our registration template file can read this attribute now.

Recaptcha also has the requirement of loading a JavaScript script. You can do this by calling LoginFormsProvider.addScript() passing in the URL.

For user profile processing, there is no additional information that it needs to add to the form, so its buildPage() method is empty.

The next meaty part of this interface is the validate() method. This is called immediately upon receiving a form post. Let’s look at the Recaptcha’s plugin first.

    @Override
    public void validate(ValidationContext context) {
        MultivaluedMap<String, String> formData = context.getHttpRequest().getDecodedFormParameters();
        List<FormMessage> errors = new ArrayList<>();
        boolean success = false;

        String captcha = formData.getFirst(G_RECAPTCHA_RESPONSE);
        if (!Validation.isBlank(captcha)) {
            AuthenticatorConfigModel captchaConfig = context.getAuthenticatorConfig();
            String secret = captchaConfig.getConfig().get(SITE_SECRET);

            success = validateRecaptcha(context, success, captcha, secret);
        }
        if (success) {
            context.success();
        } else {
            errors.add(new FormMessage(null, Messages.RECAPTCHA_FAILED));
            formData.remove(G_RECAPTCHA_RESPONSE);
            context.validationError(formData, errors);
            return;


        }
    }

Here we obtain the form data that the Recaptcha widget adds to the form. We obtain the Recaptcha secret key from configuration. We then validate the recaptcha. If successful, ValidationContext.success() is called. If not, we invoke ValidationContext.validationError() passing in the formData (so the user doesn’t have to re-enter data), we also specify an error message we want displayed. The error message must point to a message bundle property in the internationalized message bundles. For other registration extensions validate() might be validating the format of a form element, for example an alternative email attribute.

Let’s also look at the user profile plugin that is used to validate email address and other user information when registering.

    @Override
    public void validate(ValidationContext context) {
        MultivaluedMap<String, String> formData = context.getHttpRequest().getDecodedFormParameters();
        context.getEvent().detail(Details.REGISTER_METHOD, "form");

        UserProfile profile = getOrCreateUserProfile(context, formData);

        try {
            profile.validate();
        } catch (ValidationException pve) {
            List<FormMessage> errors = Validation.getFormErrorsFromValidation(pve.getErrors());

            if (pve.hasError(Messages.EMAIL_EXISTS, Messages.INVALID_EMAIL)) {
                context.getEvent().detail(Details.EMAIL, profile.getAttributes().getFirstValue(UserModel.EMAIL));
            }

            if (pve.hasError(Messages.EMAIL_EXISTS)) {
                context.error(Errors.EMAIL_IN_USE);
            } else if (pve.hasError(Messages.USERNAME_EXISTS)) {
                context.error(Errors.USERNAME_IN_USE);
            } else {
                context.error(Errors.INVALID_REGISTRATION);
            }

            context.validationError(formData, errors);
            return;
        }
        context.success();
    }

As you can see, this validate() method of user profile processing makes sure that the email and all other attributes are filled in the form. It delegates to User Profile SPI, which makes sure that email is in the right format and does all other validations. If any of these validations fail, an error message is queued up for rendering. It would contain the message for every field where the validation failed.

As you can see, the user profile makes sure that registration form contains all the needed user profile fields. User profile also makes sure that correct validations are used, attributes are correctly grouped on the page. There is a correct type used for each field (such as if a user needs to choose from predefined values), fields are "conditionally" rendered just for some scopes (Progressive profiling) and others. So usually you will not need to implement new FormAction or registration fields, but you can just properly configure user-profile to reflect this. For more details, see User Profile documentation. In general, new FormAction might be useful for instance if you want to add new credentials to the registration form (such as ReCaptcha support as mentioned here) rather than new user profile fields.

After all validations have been processed then, the form flow then invokes the FormAction.success() method. For recaptcha this is a no-op, so we won’t go over it. For user profile processing, this method fills in values in the registered user.

    @Override
    public void success(FormContext context) {
        checkNotOtherUserAuthenticating(context);

        MultivaluedMap<String, String> formData = context.getHttpRequest().getDecodedFormParameters();

        String email = formData.getFirst(UserModel.EMAIL);
        String username = formData.getFirst(UserModel.USERNAME);

        if (context.getRealm().isRegistrationEmailAsUsername()) {
            username = email;
        }

        context.getEvent().detail(Details.USERNAME, username)
                .detail(Details.REGISTER_METHOD, "form")
                .detail(Details.EMAIL, email);

        UserProfile profile = getOrCreateUserProfile(context, formData);
        UserModel user = profile.create();

        user.setEnabled(true);

        // This means that following actions can retrieve user from the context by context.getUser() method
        context.setUser(user);
    }

The new user is created and the UserModel of the newly registered user is added to the FormContext. The appropriate methods are called to initialize UserModel data. In your own FormAction, you can possibly obtain user by using something like:

    @Override
    public void success(FormContext context) {
        UserModel user = context.getUser();
        if (user != null) {
            // Do something useful with the user here ...
        }
    }

Finally, you are also required to define a FormActionFactory class. This class is implemented similarly to AuthenticatorFactory, so we won’t go over it.

Packaging the action

You will package your classes within a single jar. This jar must contain a file named org.keycloak.authentication.FormActionFactory and must be contained in the META-INF/services/ directory of your jar. This file must list the fully qualified class name of each FormActionFactory implementation you have in the jar. For example:

org.keycloak.authentication.forms.RegistrationUserCreation
org.keycloak.authentication.forms.RegistrationRecaptcha

This services/ file is used by Keycloak to scan the providers it has to load into the system.

To deploy this jar, copy it to the providers/ directory, then run bin/kc.[sh|bat] build.

Adding FormAction to the registration flow

Adding a FormAction to a registration page flow must be done in the Admin Console. If you go to the Authentication menu item and go to the Flow tab, you will be able to view the currently defined flows. You cannot modify built in flows, so, to add the Authenticator we’ve created you have to copy an existing flow or create your own. I’m hoping the UI is intuitive enough so that you can figure out for yourself how to create a flow and add the FormAction.

Basically you’ll have to copy the registration flow. Then click Actions menu to the right of the Registration Form, and pick "Add execution" to add a new execution. You’ll pick the FormAction from the selection list. Make sure your FormAction comes after "Registration User Creation" by using the down buttons to move it if your FormAction isn’t already listed after "Registration User Creation". You want your FormAction to come after user creation because the success() method of Registration User Creation is responsible for creating the new UserModel.

After you’ve created your flow, you have to bind it to registration. If you go to the Authentication menu and go to the Bindings tab you will see options to bind a flow to the browser, registration, or direct grant flow.

Modifying forgot password/credential flow

Keycloak also has a specific authentication flow for forgot password, or rather credential reset initiated by a user. If you go to the Admin Console flows page, there is a "reset credentials" flow. By default, Keycloak asks for the email or username of the user and sends an email to them. If the user clicks on the link, then they are able to reset both their password and OTP (if an OTP has been set up). You can disable automatic OTP reset by disabling the "Reset OTP" authenticator in the flow.

You can add additional functionality to this flow as well. For example, many deployments would like for the user to answer one or more secret questions in additional to sending an email with a link. You could expand on the secret question example that comes with the distro and incorporate it into the reset credential flow.

One thing to note if you are extending the reset credentials flow. The first "authenticator" is just a page to obtain the username or email. If the username or email exists, then the AuthenticationFlowContext.getUser() will return the located user. Otherwise this will be null. This form WILL NOT re-ask the user to enter an email or username if the previous email or username did not exist. You need to prevent attackers from being able to guess valid users. So, if AuthenticationFlowContext.getUser() returns null, you should proceed with the flow to make it look like a valid user was selected. I suggest that if you want to add secret questions to this flow, you should ask these questions after the email is sent. In other words, add your custom authenticator after the "Send Reset Email" authenticator.

Modifying first broker login flow

First Broker Login flow is used during first login with some identity provider. Term First Login means that there is not yet existing Keycloak account linked with the particular authenticated identity provider account.

Additional resources

Authentication of clients

Keycloak actually supports pluggable authentication for OpenID Connect client applications. Authentication of client (application) is used under the hood by the Keycloak adapter during sending any backchannel requests to the Keycloak server (like the request for exchange code to access token after successful authentication or request to refresh token). But the client authentication can be also used directly by you during Direct Access grants (represented by OAuth2 Resource Owner Password Credentials Flow) or during Service account authentication (represented by OAuth2 Client Credentials Flow).

Additional resources

Default implementations

Actually Keycloak has 2 default implementations of client authentication:

Traditional authentication with client_id and client_secret

This is default mechanism mentioned in the OpenID Connect or OAuth2 specification and Keycloak supports it since it’s early days. The public client needs to include client_id parameter with its ID in the POST request (so it’s de facto not authenticated) and the confidential client needs to include Authorization: Basic header with the clientId and clientSecret used as username and password.

Authentication with signed JWT

This is based on the JWT Bearer Token Profiles for OAuth 2.0 specification. The client/adapter generates the JWT and signs it with his private key. The Keycloak then verifies the signed JWT with the client’s public key and authenticates client based on it.

See the demo example and especially the examples/preconfigured-demo/product-app for the example application showing the application using client authentication with signed JWT.

Implement your own client authenticator

For plug your own client authenticator, you need to implement few interfaces on both client (adapter) and server side.

Client side

Here you need to implement org.keycloak.adapters.authentication.ClientCredentialsProvider and put the implementation either to:

  • your WAR file into WEB-INF/classes . But in this case, the implementation can be used just for this single WAR application

  • Some JAR file, which will be added into WEB-INF/lib of your WAR

  • Some JAR file, which will be used as jboss module and configured in jboss-deployment-structure.xml of your WAR. In all cases, you also need to create the file META-INF/services/org.keycloak.adapters.authentication.ClientCredentialsProvider either in the WAR or in your JAR.

Server side

Here you need to implement org.keycloak.authentication.ClientAuthenticatorFactory and org.keycloak.authentication.ClientAuthenticator . You also need to add the file META-INF/services/org.keycloak.authentication.ClientAuthenticatorFactory with the name of the implementation classes. See authenticators for more details.

Action Token Handler SPI

An action token is a special instance of Json Web Token (JWT) that permits its bearer to perform some actions, e.g. to reset a password or validate e-mail address. They are usually sent to users in form of a link that points to an endpoint processing action tokens for a particular realm.

Keycloak offers four basic token types allowing the bearer to:

  • Reset credentials

  • Confirm e-mail address

  • Execute required action(s)

  • Confirm linking of an account with account in external identity provider

In addition to that, it is possible to implement any functionality that initiates or modifies authentication session using action token handler SPI, details of which are described in the text below.

Anatomy of action token

Action token is a standard Json Web Token signed with active realm key where the payload contains several fields:

  • typ - Identification of the action (e.g. verify-email)

  • iat and exp - Times of token validity

  • sub - ID of the user

  • azp - Client name

  • iss - Issuer - URL of the issuing realm

  • aud - Audience - list containing URL of the issuing realm

  • asid - ID of the authentication session (optional)

  • nonce - Random nonce to guarantee uniqueness of use if the operation can only be executed once (optional)

In addition, an action token can contain any number of custom fields serializable into JSON.

Action token processing

When an action token is passed to a Keycloak endpoint KEYCLOAK_ROOT/realms/master/login-actions/action-token via key parameter, it is validated and a proper action token handler is executed. The processing always takes place in a context of an authentication session, either a fresh one or the action token service joins an existing authentication session (details are described below). The action token handler can perform actions prescribed by the token (often it alters the authentication session) and results into an HTTP response (e.g. it can continue in authentication or display an information/error page). These steps are detailed below.

  1. Basic action token validation. Signature and time validity is checked, and action token handler is determined based on typ field.

  2. Determining authentication session. If the action token URL was opened in browser with existing authentication session, and the token contains authentication session ID matching the authentication session from the browser, action token validation and handling will attach this ongoing authentication session. Otherwise, action token handler creates a fresh authentication session that replaces any other authentication session present at that time in the browser.

  3. Token validations specific for token type. Action token endpoint logic validates that the user (sub field) and client (azp) from the token exist, are valid and not disabled. Then it validates all custom validations defined in the action token handler. Furthermore, token handler can request this token be single-use. Already used tokens would then be rejected by action token endpoint logic.

  4. Performing the action. After all these validations, action token handler code is called that performs the actual action according to parameters in the token.

  5. Invalidation of single-Use tokens. If the token is set to single-use, once the authentication flow finishes, the action token is invalidated.

Implement your own action token and its handler

How to create an action token

As action token is just a signed JWT with few mandatory fields (see Anatomy of action token above), it can be serialized and signed as such using Keycloak’s JWSBuilder class. This way has been already implemented in serialize(session, realm, uriInfo) method of org.keycloak.authentication.actiontoken.DefaultActionToken and can be leveraged by implementors by using that class for tokens instead of plain JsonWebToken.

The following example shows the implementation of a simple action token. Note that the class must have a private constructor without any arguments. This is necessary to deserialize the token class from JWT.

import org.keycloak.authentication.actiontoken.DefaultActionToken;

public class DemoActionToken extends DefaultActionToken {

    public static final String TOKEN_TYPE = "my-demo-token";

    public DemoActionToken(String userId, int absoluteExpirationInSecs, String compoundAuthenticationSessionId) {
        super(userId, TOKEN_TYPE, absoluteExpirationInSecs, null, compoundAuthenticationSessionId);
    }

    private DemoActionToken() {
        // Required to deserialize from JWT
        super();
    }
}

If the action token you are implementing contains any custom fields that should be serializabled to JSON fields, you should consider implementing a descendant of org.keycloak.representations.JsonWebToken class that would implement org.keycloak.models.ActionTokenKeyModel interface. In that case, you can take advantage of the existing org.keycloak.authentication.actiontoken.DefaultActionToken class as it already satisfies both these conditions, and either use it directly or implement its child, the fields of which can be annotated with appropriate Jackson annotations, e.g. com.fasterxml.jackson.annotation.JsonProperty to serialize them to JSON.

The following example extends the DemoActionToken from the previous example with the field demo-id:

import com.fasterxml.jackson.annotation.JsonProperty;
import org.keycloak.authentication.actiontoken.DefaultActionToken;

public class DemoActionToken extends DefaultActionToken {

    public static final String TOKEN_TYPE = "my-demo-token";

    private static final String JSON_FIELD_DEMO_ID = "demo-id";

    @JsonProperty(value = JSON_FIELD_DEMO_ID)
    private String demoId;

    public DemoActionToken(String userId, int absoluteExpirationInSecs, String compoundAuthenticationSessionId, String demoId) {
        super(userId, TOKEN_TYPE, absoluteExpirationInSecs, null, compoundAuthenticationSessionId);
        this.demoId =  demoId;
    }

    private DemoActionToken() {
        // you must have this private constructor for deserializer
    }

    public String getDemoId() {
        return demoId;
    }
}

Packaging classes and deployment

To plug your own action token and its handler, you need to implement few interfaces on server side:

  • org.keycloak.authentication.actiontoken.ActionTokenHandler - actual handler of action token for a particular action (i.e. for a given value of typ token field).

    The central method in that interface is handleToken(token, context) which defines actual operation executed upon receiving the action token. Usually it is some alteration of authentication session notes but generally it can be arbitrary. This method is only called if all verifiers (including those defined in getVerifiers(context)) have succeeded, and it is guaranteed that the token would be of the class returned by getTokenClass() method.

    To be able to determine whether the action token was issued for the current authentication session as described in Item 2 above, method for extracting authentication session ID has to be declared in getAuthenticationSessionIdFromToken(token, context) method. The implementation in DefaultActionToken returns the value of asid field from the token if it is defined. Note that you can override that method to return current authentication session ID regardless of the token - that way you can create tokens that would step into the ongoing authentication flow before any authentication flow would be started.

    If the authentication session from the token does not match the current one, the action token handler would be asked to start a fresh one by calling startFreshAuthenticationSession(token, context). It can throw a VerificationException (or better its more descriptive variant ExplainedTokenVerificationException) to signal that would be forbidden.

    The token handler also determines via method canUseTokenRepeatedly(token, context) whether the token would be invalidated after it is used and authentication completes. Note that if you would have a flow utilizing multiple action token, only the last token would be invalidated. In that case, you should use org.keycloak.models.SingleUseObjectProvider in action token handler to invalidate the used tokens manually.

    Default implementation of most of the ActionTokenHandler methods is the org.keycloak.authentication.actiontoken.AbstractActionTokenHandler abstract class in keycloak-services module. The only method that needs to be implemented is handleToken(token, context) that performs the actual action.

  • org.keycloak.authentication.actiontoken.ActionTokenHandlerFactory - factory that instantiates action token handler. Implementations have to override getId() to return value that must match precisely the value of typ field in the action token.

    Note that you have to register the custom ActionTokenHandlerFactory implementation as explained in the Service Provider Interfaces section of this guide.

Event Listener SPI

Writing an Event Listener Provider starts by implementing the EventListenerProvider and EventListenerProviderFactory interfaces. Please see the Javadoc and examples for complete details on how to do this.

For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter.

SAML role mappings SPI

Keycloak defines an SPI for mapping SAML roles into roles that exist in the SP environment. The roles returned by a third-party IDP might not always correspond to the roles that were defined for the SP application so there is a need for a mechanism that allows mapping the SAML roles into different roles. It is used by the SAML adapter after it extracts the roles from the SAML assertion to set up the container’s security context.

The org.keycloak.adapters.saml.RoleMappingsProvider SPI doesn’t impose any restrictions on the mappings that can be performed. Implementations can not only map roles into other roles but also add or remove roles (and thus augment or reduce the set of roles assigned to the SAML principal) depending on the use case.

For details about the configuration of the role mappings provider for the SAML adapter as well as a description of the default implementations available see the Securing Applications and Services Guide.

Implementing a custom role mappings provider

To implement a custom role mappings provider one first needs to implement the org.keycloak.adapters.saml.RoleMappingsProvider interface. Then, a META-INF/services/org.keycloak.adapters.saml.RoleMappingsProvider file containing the fully qualified name of the custom implementation must be added to the archive that also contains the implementation class. This archive can be:

  • The SP application WAR file where the provider class is included in WEB-INF/classes;

  • A custom JAR file which will be added into WEB-INF/lib of the SP application WAR;

  • (WildFly/JBoss EAP only) A custom JAR file configured as a jboss module and referenced in jboss-deployment-structure.xml of the SP application WAR.

When the SP application is deployed, the role mappings provider that will be used is selected by the id that was set in keycloak-saml.xml or in the keycloak-saml subsystem. So to enable your custom provider simply make sure that its id is properly set in the adapter configuration.

User Storage SPI

You can use the User Storage SPI to write extensions to Keycloak to connect to external user databases and credential stores. The built-in LDAP and ActiveDirectory support is an implementation of this SPI in action. Out of the box, Keycloak uses its local database to create, update, and look up users and validate credentials. Often though, organizations have existing external proprietary user databases that they cannot migrate to Keycloak’s data model. For those situations, application developers can write implementations of the User Storage SPI to bridge the external user store and the internal user object model that Keycloak uses to log in users and manage them.

When the Keycloak runtime needs to look up a user, such as when a user is logging in, it performs a number of steps to locate the user. It first looks to see if the user is in the user cache; if the user is found it uses that in-memory representation. Then it looks for the user within the Keycloak local database. If the user is not found, it then loops through User Storage SPI provider implementations to perform the user query until one of them returns the user the runtime is looking for. The provider queries the external user store for the user and maps the external data representation of the user to Keycloak’s user metamodel.

User Storage SPI provider implementations can also perform complex criteria queries, perform CRUD operations on users, validate and manage credentials, or perform bulk updates of many users at once. It depends on the capabilities of the external store.

User Storage SPI provider implementations are packaged and deployed similarly to (and often are) Jakarta EE components. They are not enabled by default, but instead must be enabled and configured per realm under the User Federation tab in the administration console.

If your user provider implementation is using some user attributes as the metadata attributes for linking/establishing the user identity, then please make sure that users are not able to edit the attributes and the corresponding attributes are read-only. The example is the LDAP_ID attribute, which the built-in Keycloak LDAP provider is using for to store the ID of the user on the LDAP server side. See the details in the Threat model mitigation chapter.

There are two sample projects in Keycloak Quickstarts Repository. Each quickstart has a README file with instructions on how to build, deploy, and test the sample project. The following table provides a brief description of the available User Storage SPI quickstarts:

Table 1. User Storage SPI Quickstarts
Name Description

user-storage-jpa

Demonstrates implementing a user storage provider using EJB and JPA.

user-storage-simple

Demonstrates implementing a user storage provider using a simple properties file that contains username/password key pairs.

Provider interfaces

When building an implementation of the User Storage SPI you have to define a provider class and a provider factory. Provider class instances are created per transaction by provider factories. Provider classes do all the heavy lifting of user lookup and other user operations. They must implement the org.keycloak.storage.UserStorageProvider interface.

package org.keycloak.storage;

public interface UserStorageProvider extends Provider {


    /**
     * Callback when a realm is removed.  Implement this if, for example, you want to do some
     * cleanup in your user storage when a realm is removed
     *
     * @param realm
     */
    default
    void preRemove(RealmModel realm) {

    }

    /**
     * Callback when a group is removed.  Allows you to do things like remove a user
     * group mapping in your external store if appropriate
     *
     * @param realm
     * @param group
     */
    default
    void preRemove(RealmModel realm, GroupModel group) {

    }

    /**
     * Callback when a role is removed.  Allows you to do things like remove a user
     * role mapping in your external store if appropriate

     * @param realm
     * @param role
     */
    default
    void preRemove(RealmModel realm, RoleModel role) {

    }

}

You may be thinking that the UserStorageProvider interface is pretty sparse? You’ll see later in this chapter that there are other mix-in interfaces your provider class may implement to support the meat of user integration.

UserStorageProvider instances are created once per transaction. When the transaction is complete, the UserStorageProvider.close() method is invoked and the instance is then garbage collected. Instances are created by provider factories. Provider factories implement the org.keycloak.storage.UserStorageProviderFactory interface.

package org.keycloak.storage;

/**
 * @author <a href="mailto:bill@burkecentral.com">Bill Burke</a>
 * @version $Revision: 1 $
 */
public interface UserStorageProviderFactory<T extends UserStorageProvider> extends ComponentFactory<T, UserStorageProvider> {

    /**
     * This is the name of the provider and will be shown in the admin console as an option.
     *
     * @return
     */
    @Override
    String getId();

    /**
     * called per Keycloak transaction.
     *
     * @param session
     * @param model
     * @return
     */
    T create(KeycloakSession session, ComponentModel model);
...
}

Provider factory classes must specify the concrete provider class as a template parameter when implementing the UserStorageProviderFactory. This is a must as the runtime will introspect this class to scan for its capabilities (the other interfaces it implements). So for example, if your provider class is named FileProvider, then the factory class should look like this:

public class FileProviderFactory implements UserStorageProviderFactory<FileProvider> {

    public String getId() { return "file-provider"; }

    public FileProvider create(KeycloakSession session, ComponentModel model) {
       ...
    }

The getId() method returns the name of the User Storage provider. This id will be displayed in the admin console’s User Federation page when you want to enable the provider for a specific realm.

The create() method is responsible for allocating an instance of the provider class. It takes a org.keycloak.models.KeycloakSession parameter. This object can be used to look up other information and metadata as well as provide access to various other components within the runtime. The ComponentModel parameter represents how the provider was enabled and configured within a specific realm. It contains the instance id of the enabled provider as well as any configuration you may have specified for it when you enabled through the admin console.

The UserStorageProviderFactory has other capabilities as well which we will go over later in this chapter.

Provider capability interfaces

If you have examined the UserStorageProvider interface closely you might notice that it does not define any methods for locating or managing users. These methods are actually defined in other capability interfaces depending on what scope of capabilities your external user store can provide and execute on. For example, some external stores are read-only and can only do simple queries and credential validation. You will only be required to implement the capability interfaces for the features you are able to. You can implement these interfaces:

SPI Description

org.keycloak.storage.user.UserLookupProvider

This interface is required if you want to be able to log in with users from this external store. Most (all?) providers implement this interface.

org.keycloak.storage.user.UserQueryMethodsProvider

Defines complex queries that are used to locate one or more users. You must implement this interface if you want to view and manage users from the administration console.

org.keycloak.storage.user.UserCountMethodsProvider

Implement this interface if your provider supports count queries.

org.keycloak.storage.user.UserQueryProvider

This interface is combined capability of UserQueryMethodsProvider and UserCountMethodsProvider.

org.keycloak.storage.user.UserRegistrationProvider

Implement this interface if your provider supports adding and removing users.

org.keycloak.storage.user.UserBulkUpdateProvider

Implement this interface if your provider supports bulk update of a set of users.

org.keycloak.credential.CredentialInputValidator

Implement this interface if your provider can validate one or more different credential types (for example, if your provider can validate a password).

org.keycloak.credential.CredentialInputUpdater

Implement this interface if your provider supports updating one or more different credential types.

Model interfaces

Most of the methods defined in the capability interfaces either return or are passed in representations of a user. These representations are defined by the org.keycloak.models.UserModel interface. App developers are required to implement this interface. It provides a mapping between the external user store and the user metamodel that Keycloak uses.

package org.keycloak.models;

public interface UserModel extends RoleMapperModel {
    String getId();

    String getUsername();
    void setUsername(String username);

    String getFirstName();
    void setFirstName(String firstName);

    String getLastName();
    void setLastName(String lastName);

    String getEmail();
    void setEmail(String email);
...
}

UserModel implementations provide access to read and update metadata about the user including things like username, name, email, role and group mappings, as well as other arbitrary attributes.

There are other model classes within the org.keycloak.models package that represent other parts of the Keycloak metamodel: RealmModel, RoleModel, GroupModel, and ClientModel.

Storage Ids

One important method of UserModel is the getId() method. When implementing UserModel developers must be aware of the user id format. The format must be:

"f:" + component id + ":" + external id

The Keycloak runtime often has to look up users by their user id. The user id contains enough information so that the runtime does not have to query every single UserStorageProvider in the system to find the user.

The component id is the id returned from ComponentModel.getId(). The ComponentModel is passed in as a parameter when creating the provider class so you can get it from there. The external id is information your provider class needs to find the user in the external store. This is often a username or a uid. For example, it might look something like this:

f:332a234e31234:wburke

When the runtime does a lookup by id, the id is parsed to obtain the component id. The component id is used to locate the UserStorageProvider that was originally used to load the user. That provider is then passed the id. The provider again parses the id to obtain the external id and it will use to locate the user in external user storage.

Packaging and deployment

In order for Keycloak to recognize the provider, you need to add a file to the JAR: META-INF/services/org.keycloak.storage.UserStorageProviderFactory. This file must contain a line-separated list of fully qualified classnames of the UserStorageProviderFactory implementations:

org.keycloak.examples.federation.properties.ClasspathPropertiesStorageFactory
org.keycloak.examples.federation.properties.FilePropertiesStorageFactory

To deploy this jar, copy it to the providers/ directory, then run bin/kc.[sh|bat] build.

Simple read-only, lookup example

To illustrate the basics of implementing the User Storage SPI let’s walk through a simple example. In this chapter you’ll see the implementation of a simple UserStorageProvider that looks up users in a simple property file. The property file contains username and password definitions and is hardcoded to a specific location on the classpath. The provider will be able to look up the user by ID and username and also be able to validate passwords. Users that originate from this provider will be read-only.

Provider class

The first thing we will walk through is the UserStorageProvider class.

public class PropertyFileUserStorageProvider implements
        UserStorageProvider,
        UserLookupProvider,
        CredentialInputValidator,
        CredentialInputUpdater
{
...
}

Our provider class, PropertyFileUserStorageProvider, implements many interfaces. It implements the UserStorageProvider as that is a base requirement of the SPI. It implements the UserLookupProvider interface because we want to be able to log in with users stored by this provider. It implements the CredentialInputValidator interface because we want to be able to validate passwords entered in using the login screen. Our property file is read-only. We implement the CredentialInputUpdater because we want to post an error condition when the user attempts to update his password.

    protected KeycloakSession session;
    protected Properties properties;
    protected ComponentModel model;
    // map of loaded users in this transaction
    protected Map<String, UserModel> loadedUsers = new HashMap<>();

    public PropertyFileUserStorageProvider(KeycloakSession session, ComponentModel model, Properties properties) {
        this.session = session;
        this.model = model;
        this.properties = properties;
    }

The constructor for this provider class is going to store the reference to the KeycloakSession, ComponentModel, and property file. We’ll use all of these later. Also notice that there is a map of loaded users. Whenever we find a user we will store it in this map so that we avoid re-creating it again within the same transaction. This is a good practice to follow as many providers will need to do this (that is, any provider that integrates with JPA). Remember also that provider class instances are created once per transaction and are closed after the transaction completes.

UserLookupProvider implementation
    @Override
    public UserModel getUserByUsername(RealmModel realm, String username) {
        UserModel adapter = loadedUsers.get(username);
        if (adapter == null) {
            String password = properties.getProperty(username);
            if (password != null) {
                adapter = createAdapter(realm, username);
                loadedUsers.put(username, adapter);
            }
        }
        return adapter;
    }

    protected UserModel createAdapter(RealmModel realm, String username) {
        return new AbstractUserAdapter(session, realm, model) {
            @Override
            public String getUsername() {
                return username;
            }
        };
    }

    @Override
    public UserModel getUserById(RealmModel realm, String id) {
        StorageId storageId = new StorageId(id);
        String username = storageId.getExternalId();
        return getUserByUsername(realm, username);
    }

    @Override
    public UserModel getUserByEmail(RealmModel realm, String email) {
        return null;
    }

The getUserByUsername() method is invoked by the Keycloak login page when a user logs in. In our implementation we first check the loadedUsers map to see if the user has already been loaded within this transaction. If it hasn’t been loaded we look in the property file for the username. If it exists we create an implementation of UserModel, store it in loadedUsers for future reference, and return this instance.

The createAdapter() method uses the helper class org.keycloak.storage.adapter.AbstractUserAdapter. This provides a base implementation for UserModel. It automatically generates a user id based on the required storage id format using the username of the user as the external id.

"f:" + component id + ":" + username

Every get method of AbstractUserAdapter either returns null or empty collections. However, methods that return role and group mappings will return the default roles and groups configured for the realm for every user. Every set method of AbstractUserAdapter will throw a org.keycloak.storage.ReadOnlyException. So if you attempt to modify the user in the Admin Console, you will get an error.

The getUserById() method parses the id parameter using the org.keycloak.storage.StorageId helper class. The StorageId.getExternalId() method is invoked to obtain the username embedded in the id parameter. The method then delegates to getUserByUsername().

Emails are not stored, so the getUserByEmail() method returns null.

CredentialInputValidator implementation

Next let’s look at the method implementations for CredentialInputValidator.

    @Override
    public boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType) {
        String password = properties.getProperty(user.getUsername());
        return credentialType.equals(PasswordCredentialModel.TYPE) && password != null;
    }

    @Override
    public boolean supportsCredentialType(String credentialType) {
        return credentialType.equals(PasswordCredentialModel.TYPE);
    }

    @Override
    public boolean isValid(RealmModel realm, UserModel user, CredentialInput input) {
        if (!supportsCredentialType(input.getType())) return false;

        String password = properties.getProperty(user.getUsername());
        if (password == null) return false;
        return password.equals(input.getChallengeResponse());
    }

The isConfiguredFor() method is called by the runtime to determine if a specific credential type is configured for the user. This method checks to see that the password is set for the user.

The supportsCredentialType() method returns whether validation is supported for a specific credential type. We check to see if the credential type is password.

The isValid() method is responsible for validating passwords. The CredentialInput parameter is really just an abstract interface for all credential types. We make sure that we support the credential type and also that it is an instance of UserCredentialModel. When a user logs in through the login page, the plain text of the password input is put into an instance of UserCredentialModel. The isValid() method checks this value against the plain text password stored in the properties file. A return value of true means the password is valid.

CredentialInputUpdater implementation

As noted before, the only reason we implement the CredentialInputUpdater interface in this example is to forbid modifications of user passwords. The reason we have to do this is because otherwise the runtime would allow the password to be overridden in Keycloak local storage. We’ll talk more about this later in this chapter.

    @Override
    public boolean updateCredential(RealmModel realm, UserModel user, CredentialInput input) {
        if (input.getType().equals(PasswordCredentialModel.TYPE)) throw new ReadOnlyException("user is read only for this update");

        return false;
    }

    @Override
    public void disableCredentialType(RealmModel realm, UserModel user, String credentialType) {

    }

    @Override
    public Stream<String> getDisableableCredentialTypesStream(RealmModel realm, UserModel user) {
        return Stream.empty();
    }

The updateCredential() method just checks to see if the credential type is password. If it is, a ReadOnlyException is thrown.

Provider factory implementation

Now that the provider class is complete, we now turn our attention to the provider factory class.

public class PropertyFileUserStorageProviderFactory
                 implements UserStorageProviderFactory<PropertyFileUserStorageProvider> {

    public static final String PROVIDER_NAME = "readonly-property-file";

    @Override
    public String getId() {
        return PROVIDER_NAME;
    }

First thing to notice is that when implementing the UserStorageProviderFactory class, you must pass in the concrete provider class implementation as a template parameter. Here we specify the provider class we defined before: PropertyFileUserStorageProvider.

If you do not specify the template parameter, your provider will not function. The runtime does class introspection to determine the capability interfaces that the provider implements.

The getId() method identifies the factory in the runtime and will also be the string shown in the admin console when you want to enable a user storage provider for the realm.

Initialization
    private static final Logger logger = Logger.getLogger(PropertyFileUserStorageProviderFactory.class);
    protected Properties properties = new Properties();

    @Override
    public void init(Config.Scope config) {
        InputStream is = getClass().getClassLoader().getResourceAsStream("/users.properties");

        if (is == null) {
            logger.warn("Could not find users.properties in classpath");
        } else {
            try {
                properties.load(is);
            } catch (IOException ex) {
                logger.error("Failed to load users.properties file", ex);
            }
        }
    }

    @Override
    public PropertyFileUserStorageProvider create(KeycloakSession session, ComponentModel model) {
        return new PropertyFileUserStorageProvider(session, model, properties);
    }

The UserStorageProviderFactory interface has an optional init() method you can implement. When Keycloak boots up, only one instance of each provider factory is created. Also at boot time, the init() method is called on each of these factory instances. There’s also a postInit() method you can implement as well. After each factory’s init() method is invoked, their postInit() methods are called.

In our init() method implementation, we find the property file containing our user declarations from the classpath. We then load the properties field with the username and password combinations stored there.

The Config.Scope parameter is factory configuration that configured through server configuration.

For example, by running the server with the following argument:

kc.[sh|bat] start --spi-storage-readonly-property-file-path=/other-users.properties

We can specify the classpath of the user property file instead of hardcoding it. Then you can retrieve the configuration in the PropertyFileUserStorageProviderFactory.init():

public void init(Config.Scope config) {
    String path = config.get("path");
    InputStream is = getClass().getClassLoader().getResourceAsStream(path);

    ...
}
Create method

Our last step in creating the provider factory is the create() method.

    @Override
    public PropertyFileUserStorageProvider create(KeycloakSession session, ComponentModel model) {
        return new PropertyFileUserStorageProvider(session, model, properties);
    }

We simply allocate the PropertyFileUserStorageProvider class. This create method will be called once per transaction.

Packaging and deployment

The class files for our provider implementation should be placed in a jar. You also have to declare the provider factory class within the META-INF/services/org.keycloak.storage.UserStorageProviderFactory file.

org.keycloak.examples.federation.properties.FilePropertiesStorageFactory

To deploy this jar, copy it to the providers/ directory, then run bin/kc.[sh|bat] build.

Enabling the provider in the Admin Console

You enable user storage providers per realm within the User Federation page in the Admin Console.

User Federation

empty user federation page

Procedure
  1. Select the provider we just created from the list: readonly-property-file.

    The configuration page for our provider displays.

  2. Click Save because we have nothing to configure.

    Configured Provider

    storage provider created

  3. Return to the main User Federation page

    You now see your provider listed.

    User Federation

    user federation page

You will now be able to log in with a user declared in the users.properties file. This user will only be able to view the account page after logging in.

Configuration techniques

Our PropertyFileUserStorageProvider example is a bit contrived. It is hardcoded to a property file that is embedded in the jar of the provider, which is not terribly useful. We might want to make the location of this file configurable per instance of the provider. In other words, we might want to reuse this provider multiple times in multiple different realms and point to completely different user property files. We’ll also want to perform this configuration within the Admin Console UI.

The UserStorageProviderFactory has additional methods you can implement that handle provider configuration. You describe the variables you want to configure per provider and the Admin Console automatically renders a generic input page to gather this configuration. When implemented, callback methods also validate the configuration before it is saved, when a provider is created for the first time, and when it is updated. UserStorageProviderFactory inherits these methods from the org.keycloak.component.ComponentFactory interface.

    List<ProviderConfigProperty> getConfigProperties();

    default
    void validateConfiguration(KeycloakSession session, RealmModel realm, ComponentModel model)
            throws ComponentValidationException
    {

    }

    default
    void onCreate(KeycloakSession session, RealmModel realm, ComponentModel model) {

    }

    default
    void onUpdate(KeycloakSession session, RealmModel realm, ComponentModel model) {

    }

The ComponentFactory.getConfigProperties() method returns a list of org.keycloak.provider.ProviderConfigProperty instances. These instances declare metadata that is needed to render and store each configuration variable of the provider.

Configuration example

Let’s expand our PropertyFileUserStorageProviderFactory example to allow you to point a provider instance to a specific file on disk.

PropertyFileUserStorageProviderFactory
public class PropertyFileUserStorageProviderFactory
                  implements UserStorageProviderFactory<PropertyFileUserStorageProvider> {

    protected static final List<ProviderConfigProperty> configMetadata;

    static {
        configMetadata = ProviderConfigurationBuilder.create()
                .property().name("path")
                .type(ProviderConfigProperty.STRING_TYPE)
                .label("Path")
                .defaultValue("${jboss.server.config.dir}/example-users.properties")
                .helpText("File path to properties file")
                .add().build();
    }

    @Override
    public List<ProviderConfigProperty> getConfigProperties() {
        return configMetadata;
    }

The ProviderConfigurationBuilder class is a great helper class to create a list of configuration properties. Here we specify a variable named path that is a String type. On the Admin Console configuration page for this provider, this configuration variable is labeled as Path and has a default value of ${jboss.server.config.dir}/example-users.properties. When you hover over the tooltip of this configuration option, it displays the help text, File path to properties file.

The next thing we want to do is to verify that this file exists on disk. We do not want to enable an instance of this provider in the realm unless it points to a valid user property file. To do this, we implement the validateConfiguration() method.

    @Override
    public void validateConfiguration(KeycloakSession session, RealmModel realm, ComponentModel config)
                   throws ComponentValidationException {
        String fp = config.getConfig().getFirst("path");
        if (fp == null) throw new ComponentValidationException("user property file does not exist");
        fp = EnvUtil.replace(fp);
        File file = new File(fp);
        if (!file.exists()) {
            throw new ComponentValidationException("user property file does not exist");
        }
    }

The validateConfiguration() method provides the configuration variable from the ComponentModel to verify if that file exists on disk. Notice that the use of the org.keycloak.common.util.EnvUtil.replace() method. With this method any string that includes ${} will replace that value with a system property value. The ${jboss.server.config.dir} string corresponds to the conf/ directory of our server and is really useful for this example.

Next thing we have to do is remove the old init() method. We do this because user property files are going to be unique per provider instance. We move this logic to the create() method.

    @Override
    public PropertyFileUserStorageProvider create(KeycloakSession session, ComponentModel model) {
        String path = model.getConfig().getFirst("path");

        Properties props = new Properties();
        try {
            InputStream is = new FileInputStream(path);
            props.load(is);
            is.close();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }

        return new PropertyFileUserStorageProvider(session, model, props);
    }

This logic is, of course, inefficient as every transaction reads the entire user property file from disk, but hopefully this illustrates, in a simple way, how to hook in configuration variables.

Configuring the provider in the Admin Console

Now that the configuration is enabled, you can set the path variable when you configure the provider in the Admin Console.

Configured Provider

readonly user storage provider with config

Add/Remove user and query capability interfaces

One thing we have not done with our example is allow it to add and remove users or change passwords. Users defined in our example are also not queryable or viewable in the Admin Console. To add these enhancements, our example provider must implement the UserQueryMethodsProvider (or UserQueryProvider) and UserRegistrationProvider interfaces.

Implementing UserRegistrationProvider

Use this procedure to implement adding and removing users from the particular store, we first have to be able to save our properties file to disk.

PropertyFileUserStorageProvider
    public void save() {
        String path = model.getConfig().getFirst("path");
        path = EnvUtil.replace(path);
        try {
            FileOutputStream fos = new FileOutputStream(path);
            properties.store(fos, "");
            fos.close();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

Then, the implementation of the addUser() and removeUser() methods becomes simple.

PropertyFileUserStorageProvider
    public static final String UNSET_PASSWORD="#$!-UNSET-PASSWORD";

    @Override
    public UserModel addUser(RealmModel realm, String username) {
        synchronized (properties) {
            properties.setProperty(username, UNSET_PASSWORD);
            save();
        }
        return createAdapter(realm, username);
    }

    @Override
    public boolean removeUser(RealmModel realm, UserModel user) {
        synchronized (properties) {
            if (properties.remove(user.getUsername()) == null) return false;
            save();
            return true;
        }
    }

Notice that when adding a user we set the password value of the property map to be UNSET_PASSWORD. We do this as we can’t have null values for a property in the property value. We also have to modify the CredentialInputValidator methods to reflect this.

The addUser() method will be called if the provider implements the UserRegistrationProvider interface. If your provider has a configuration switch to turn off adding a user, returning null from this method will skip the provider and call the next one.

PropertyFileUserStorageProvider
    @Override
    public boolean isValid(RealmModel realm, UserModel user, CredentialInput input) {
        if (!supportsCredentialType(input.getType()) || !(input instanceof UserCredentialModel)) return false;

        UserCredentialModel cred = (UserCredentialModel)input;
        String password = properties.getProperty(user.getUsername());
        if (password == null || UNSET_PASSWORD.equals(password)) return false;
        return password.equals(cred.getValue());
    }

Since we can now save our property file, it also makes sense to allow password updates.

PropertyFileUserStorageProvider
    @Override
    public boolean updateCredential(RealmModel realm, UserModel user, CredentialInput input) {
        if (!(input instanceof UserCredentialModel)) return false;
        if (!input.getType().equals(PasswordCredentialModel.TYPE)) return false;
        UserCredentialModel cred = (UserCredentialModel)input;
        synchronized (properties) {
            properties.setProperty(user.getUsername(), cred.getValue());
            save();
        }
        return true;
    }

We can now also implement disabling a password.

PropertyFileUserStorageProvider
    @Override
    public void disableCredentialType(RealmModel realm, UserModel user, String credentialType) {
        if (!credentialType.equals(PasswordCredentialModel.TYPE)) return;
        synchronized (properties) {
            properties.setProperty(user.getUsername(), UNSET_PASSWORD);
            save();
        }

    }

    private static final Set<String> disableableTypes = new HashSet<>();

    static {
        disableableTypes.add(PasswordCredentialModel.TYPE);
    }

    @Override
    public Stream<String> getDisableableCredentialTypes(RealmModel realm, UserModel user) {

        return disableableTypes.stream();
    }

With these methods implemented, you’ll now be able to change and disable the password for the user in the Admin Console.

Implementing UserQueryProvider

UserQueryProvider is combination of UserQueryMethodsProvider and UserCountMethodsProvider. Without implementing UserQueryMethodsProvider the Admin Console would not be able to view and manage users that were loaded by our example provider. Let’s look at implementing this interface.

PropertyFileUserStorageProvider
    @Override
    public int getUsersCount(RealmModel realm) {
        return properties.size();
    }

    @Override
    public Stream<UserModel> searchForUserStream(RealmModel realm, String search, Integer firstResult, Integer maxResults) {
        Predicate<String> predicate = "*".equals(search) ? username -> true : username -> username.contains(search);
        return properties.keySet().stream()
                .map(String.class::cast)
                .filter(predicate)
                .skip(firstResult)
                .map(username -> getUserByUsername(realm, username))
                .limit(maxResults);
    }

The first declaration of searchForUserStream() takes a String parameter. In this example, the parameter represents a username that you want to search by. This string can be a substring, which explains the choice of the String.contains() method when doing the search. Notice the use of * to indicate to request a list of all users. The method iterates over the key set of the property file, delegating to getUserByUsername() to load a user. Notice that we are indexing this call based on the firstResult and maxResults parameter. If your external store does not support pagination, you will have to do similar logic.

PropertyFileUserStorageProvider
    @Override
    public Stream<UserModel> searchForUserStream(RealmModel realm, Map<String, String> params, Integer firstResult, Integer maxResults) {
        // only support searching by username
        String usernameSearchString = params.get("username");
        if (usernameSearchString != null)
            return searchForUserStream(realm, usernameSearchString, firstResult, maxResults);

        // if we are not searching by username, return all users
        return searchForUserStream(realm, "*", firstResult, maxResults);
    }

The searchForUserStream() method that takes a Map parameter can search for a user based on first, last name, username, and email. Only usernames are stored, so the search is based only on usernames except when the Map parameter does not contain the username attribute. In this case, all users are returned. In that situation, the searchForUserStream(realm, search, firstResult, maxResults) is used.

PropertyFileUserStorageProvider
    @Override
    public Stream<UserModel> getGroupMembersStream(RealmModel realm, GroupModel group, Integer firstResult, Integer maxResults) {
        return Stream.empty();
    }

    @Override
    public Stream<UserModel> searchForUserByUserAttributeStream(RealmModel realm, String attrName, String attrValue) {
        return Stream.empty();
    }

Groups or attributes are not stored, so the other methods return an empty stream.

Augmenting external storage

The PropertyFileUserStorageProvider example is really limited. While we will be able to log in with users stored in a property file, we won’t be able to do much else. If users loaded by this provider need special role or group mappings to fully access particular applications there is no way for us to add additional role mappings to these users. You also can’t modify or add additional important attributes like email, first and last name.

For these types of situations, Keycloak allows you to augment your external store by storing extra information in Keycloak’s database. This is called federated user storage and is encapsulated within the org.keycloak.storage.federated.UserFederatedStorageProvider class.

UserFederatedStorageProvider
package org.keycloak.storage.federated;

public interface UserFederatedStorageProvider extends Provider,
        UserAttributeFederatedStorage,
        UserBrokerLinkFederatedStorage,
        UserConsentFederatedStorage,
        UserNotBeforeFederatedStorage,
        UserGroupMembershipFederatedStorage,
        UserRequiredActionsFederatedStorage,
        UserRoleMappingsFederatedStorage,
        UserFederatedUserCredentialStore {
    ...

}

The UserFederatedStorageProvider instance is available on the UserStorageUtil.userFederatedStorage(KeycloakSession) method. It has all different kinds of methods for storing attributes, group and role mappings, different credential types, and required actions. If your external store’s datamodel cannot support the full Keycloak feature set, then this service can fill in the gaps.

Keycloak comes with a helper class org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage that will delegate every single UserModel method except get/set of username to user federated storage. Override the methods you need to override to delegate to your external storage representations. It is strongly suggested you read the javadoc of this class as it has smaller protected methods you may want to override. Specifically surrounding group membership and role mappings.

Augmentation example

In our PropertyFileUserStorageProvider example, we just need a simple change to our provider to use the AbstractUserAdapterFederatedStorage.

PropertyFileUserStorageProvider
    protected UserModel createAdapter(RealmModel realm, String username) {
        return new AbstractUserAdapterFederatedStorage(session, realm, model) {
            @Override
            public String getUsername() {
                return username;
            }

            @Override
            public void setUsername(String username) {
                String pw = (String)properties.remove(username);
                if (pw != null) {
                    properties.put(username, pw);
                    save();
                }
            }
        };
    }

We instead define an anonymous class implementation of AbstractUserAdapterFederatedStorage. The setUsername() method makes changes to the properties file and saves it.

Import implementation strategy

When implementing a user storage provider, there’s another strategy you can take. Instead of using user federated storage, you can create a user locally in the Keycloak built-in user database and copy attributes from your external store into this local copy. There are many advantages to this approach.

  • Keycloak basically becomes a persistence user cache for your external store. Once the user is imported you’ll no longer hit the external store thus taking load off of it.

  • If you are moving to Keycloak as your official user store and deprecating the old external store, you can slowly migrate applications to use Keycloak. When all applications have been migrated, unlink the imported user, and retire the old legacy external store.

There are some obvious disadvantages though to using an import strategy:

  • Looking up a user for the first time will require multiple updates to Keycloak database. This can be a big performance loss under load and put a lot of strain on the Keycloak database. The user federated storage approach will only store extra data as needed and may never be used depending on the capabilities of your external store.

  • With the import approach, you have to keep local Keycloak storage and external storage in sync. The User Storage SPI has capability interfaces that you can implement to support synchronization, but this can quickly become painful and messy.

To implement the import strategy you simply check to see first if the user has been imported locally. If so return the local user, if not create the user locally and import data from the external store. You can also proxy the local user so that most changes are automatically synchronized.

This will be a bit contrived, but we can extend our PropertyFileUserStorageProvider to take this approach. We begin first by modifying the createAdapter() method.

PropertyFileUserStorageProvider
    protected UserModel createAdapter(RealmModel realm, String username) {
        UserModel local = UserStoragePrivateUtil.userLocalStorage(session).getUserByUsername(realm, username);
        if (local == null) {
            local = UserStoragePrivateUtil.userLocalStorage(session).addUser(realm, username);
            local.setFederationLink(model.getId());
        }
        return new UserModelDelegate(local) {
            @Override
            public void setUsername(String username) {
                String pw = (String)properties.remove(username);
                if (pw != null) {
                    properties.put(username, pw);
                    save();
                }
                super.setUsername(username);
            }
        };
    }

In this method we call the UserStoragePrivateUtil.userLocalStorage(session) method to obtain a reference to local Keycloak user storage. We see if the user is stored locally, if not, we add it locally. Do not set the id of the local user. Let Keycloak automatically generate the id. Also note that we call UserModel.setFederationLink() and pass in the ID of the ComponentModel of our provider. This sets a link between the provider and the imported user.

When a user storage provider is removed, any user imported by it will also be removed. This is one of the purposes of calling UserModel.setFederationLink().

Another thing to note is that if a local user is linked, your storage provider will still be delegated to for methods that it implements from the CredentialInputValidator and CredentialInputUpdater interfaces. Returning false from a validation or update will just result in Keycloak seeing if it can validate or update using local storage.

Also notice that we are proxying the local user using the org.keycloak.models.utils.UserModelDelegate class. This class is an implementation of UserModel. Every method just delegates to the UserModel it was instantiated with. We override the setUsername() method of this delegate class to synchronize automatically with the property file. For your providers, you can use this to intercept other methods on the local UserModel to perform synchronization with your external store. For example, get methods could make sure that the local store is in sync. Set methods keep the external store in sync with the local one. One thing to note is that the getId() method should always return the id that was auto generated when you created the user locally. You should not return a federated id as shown in the other non-import examples.

If your provider is implementing the UserRegistrationProvider interface, your removeUser() method does not need to remove the user from local storage. The runtime will automatically perform this operation. Also note that removeUser() will be invoked before it is removed from local storage.

ImportedUserValidation interface

If you remember earlier in this chapter, we discussed how querying for a user worked. Local storage is queried first, if the user is found there, then the query ends. This is a problem for our above implementation as we want to proxy the local UserModel so that we can keep usernames in sync. The User Storage SPI has a callback for whenever a linked local user is loaded from the local database.

package org.keycloak.storage.user;
public interface ImportedUserValidation {
    /**
     * If this method returns null, then the user in local storage will be removed
     *
     * @param realm
     * @param user
     * @return null if user no longer valid
     */
    UserModel validate(RealmModel realm, UserModel user);
}

Whenever a linked local user is loaded, if the user storage provider class implements this interface, then the validate() method is called. Here you can proxy the local user passed in as a parameter and return it. That new UserModel will be used. You can also optionally do a check to see if the user still exists in the external store. If validate() returns null, then the local user will be removed from the database.

ImportSynchronization interface

With the import strategy you can see that it is possible for the local user copy to get out of sync with external storage. For example, maybe a user has been removed from the external store. The User Storage SPI has an additional interface you can implement to deal with this, org.keycloak.storage.user.ImportSynchronization:

package org.keycloak.storage.user;

public interface ImportSynchronization {
    SynchronizationResult sync(KeycloakSessionFactory sessionFactory, String realmId, UserStorageProviderModel model);
    SynchronizationResult syncSince(Date lastSync, KeycloakSessionFactory sessionFactory, String realmId, UserStorageProviderModel model);
}

This interface is implemented by the provider factory. Once this interface is implemented by the provider factory, the administration console management page for the provider shows additional options. You can manually force a synchronization by clicking a button. This invokes the ImportSynchronization.sync() method. Also, additional configuration options are displayed that allow you to automatically schedule a synchronization. Automatic synchronizations invoke the syncSince() method.

User caches

When a user object is loaded by ID, username, or email queries it is cached. When a user object is being cached, it iterates through the entire UserModel interface and pulls this information to a local in-memory-only cache. In a cluster, this cache is still local, but it becomes an invalidation cache. When a user object is modified, it is evicted. This eviction event is propagated to the entire cluster so that the other nodes' user cache is also invalidated.

Managing the user cache

You can access the user cache by calling KeycloakSession.getProvider(UserCache.class).

/**
 * All these methods effect an entire cluster of Keycloak instances.
 *
 * @author <a href="mailto:bill@burkecentral.com">Bill Burke</a>
 * @version $Revision: 1 $
 */
public interface UserCache extends UserProvider {
    /**
     * Evict user from cache.
     *
     * @param user
     */
    void evict(RealmModel realm, UserModel user);

    /**
     * Evict users of a specific realm
     *
     * @param realm
     */
    void evict(RealmModel realm);

    /**
     * Clear cache entirely.
     *
     */
    void clear();
}

There are methods for evicting specific users, users contained in a specific realm, or the entire cache.

OnUserCache callback interface

You might want to cache additional information that is specific to your provider implementation. The User Storage SPI has a callback whenever a user is cached: org.keycloak.models.cache.OnUserCache.

public interface OnUserCache {
    void onCache(RealmModel realm, CachedUserModel user, UserModel delegate);
}

Your provider class should implement this interface if it wants this callback. The UserModel delegate parameter is the UserModel instance returned by your provider. The CachedUserModel is an expanded UserModel interface. This is the instance that is cached locally in local storage.

public interface CachedUserModel extends UserModel {

    /**
     * Invalidates the cache for this user and returns a delegate that represents the actual data provider
     *
     * @return
     */
    UserModel getDelegateForUpdate();

    boolean isMarkedForEviction();

    /**
     * Invalidate the cache for this model
     *
     */
    void invalidate();

    /**
     * When was the model was loaded from database.
     *
     * @return
     */
    long getCacheTimestamp();

    /**
     * Returns a map that contains custom things that are cached along with this model.  You can write to this map.
     *
     * @return
     */
    ConcurrentHashMap getCachedWith();
}

This CachedUserModel interface allows you to evict the user from the cache and get the provider UserModel instance. The getCachedWith() method returns a map that allows you to cache additional information pertaining to the user. For example, credentials are not part of the UserModel interface. If you wanted to cache credentials in memory, you would implement OnUserCache and cache your user’s credentials using the getCachedWith() method.

Cache policies

On the administration console management page for your user storage provider, you can specify a unique cache policy.

Leveraging Jakarta EE

Since version 20, Keycloak relies only on Quarkus. Unlike WildFly, Quarkus is not an Application Server. For more detail, see https://www.keycloak.org/migration/migrating-to-quarkus#_quarkus_is_not_an_application_server.

Therefore, the User Storage Providers cannot be packaged within any Jakarta EE component or make it an EJB as was the case when Keycloak ran over WildFly in previous versions.

Providers implementations are required to be plain java objects which implement the suitable User Storage SPI interfaces, as was explained in the previous sections. And they must be packaged and deployed as stated in this Migration Guide:

You can still implement your custom UserStorageProvider class, which is able to integrate an external database by JPA Entity Manager, as shown in this example:

CDI is not supported.

REST management API

You can create, remove, and update your user storage provider deployments through the administrator REST API. The User Storage SPI is built on top of a generic component interface so you will be using that generic API to manage your providers.

The REST Component API lives under your realm admin resource.

/admin/realms/{realm-name}/components

We will only show this REST API interaction with the Java client. Hopefully you can extract how to do this from curl from this API.

public interface ComponentsResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<ComponentRepresentation> query();

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<ComponentRepresentation> query(@QueryParam("parent") String parent);

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<ComponentRepresentation> query(@QueryParam("parent") String parent, @QueryParam("type") String type);

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<ComponentRepresentation> query(@QueryParam("parent") String parent,
                                               @QueryParam("type") String type,
                                               @QueryParam("name") String name);

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    Response add(ComponentRepresentation rep);

    @Path("{id}")
    ComponentResource component(@PathParam("id") String id);
}

public interface ComponentResource {
    @GET
    public ComponentRepresentation toRepresentation();

    @PUT
    @Consumes(MediaType.APPLICATION_JSON)
    public void update(ComponentRepresentation rep);

    @DELETE
    public void remove();
}

To create a user storage provider, you must specify the provider id, a provider type of the string org.keycloak.storage.UserStorageProvider, as well as the configuration.

import org.keycloak.admin.client.Keycloak;
import org.keycloak.representations.idm.RealmRepresentation;
...

Keycloak keycloak = Keycloak.getInstance(
    "http://localhost:8080",
    "master",
    "admin",
    "password",
    "admin-cli");
RealmResource realmResource = keycloak.realm("master");
RealmRepresentation realm = realmResource.toRepresentation();

ComponentRepresentation component = new ComponentRepresentation();
component.setName("home");
component.setProviderId("readonly-property-file");
component.setProviderType("org.keycloak.storage.UserStorageProvider");
component.setParentId(realm.getId());
component.setConfig(new MultivaluedHashMap());
component.getConfig().putSingle("path", "~/users.properties");

realmResource.components().add(component);

// retrieve a component

List<ComponentRepresentation> components = realmResource.components().query(realm.getId(),
                                                                    "org.keycloak.storage.UserStorageProvider",
                                                                    "home");
component = components.get(0);

// Update a component

component.getConfig().putSingle("path", "~/my-users.properties");
realmResource.components().component(component.getId()).update(component);

// Remove a component

realmREsource.components().component(component.getId()).remove();

Migrating from an earlier user federation SPI

This chapter is only applicable if you have implemented a provider using the earlier (and now removed) User Federation SPI.

In Keycloak version 2.4.0 and earlier there was a User Federation SPI. Red Hat Single Sign-On version 7.0, although unsupported, had this earlier SPI available as well. This earlier User Federation SPI has been removed from Keycloak version 2.5.0 and Red Hat Single Sign-On version 7.1. However, if you have written a provider with this earlier SPI, this chapter discusses some strategies you can use to port it.

Import versus non-import

The earlier User Federation SPI required you to create a local copy of a user in the Keycloak’s database and import information from your external store to the local copy. However, this is no longer a requirement. You can still port your earlier provider as-is, but you should consider whether a non-import strategy might be a better approach.

Advantages of the import strategy:

  • Keycloak basically becomes a persistence user cache for your external store. Once the user is imported you’ll no longer hit the external store, thus taking load off of it.

  • If you are moving to Keycloak as your official user store and deprecating the earlier external store, you can slowly migrate applications to use Keycloak. When all applications have been migrated, unlink the imported user, and retire the earlier legacy external store.

There are some obvious disadvantages though to using an import strategy:

  • Looking up a user for the first time will require multiple updates to Keycloak database. This can be a big performance loss under load and put a lot of strain on the Keycloak database. The user federated storage approach will only store extra data as needed and might never be used depending on the capabilities of your external store.

  • With the import approach, you have to keep local Keycloak storage and external storage in sync. The User Storage SPI has capability interfaces that you can implement to support synchronization, but this can quickly become painful and messy.

UserFederationProvider versus UserStorageProvider

The first thing to notice is that UserFederationProvider was a complete interface. You implemented every method in this interface. However, UserStorageProvider has instead broken up this interface into multiple capability interfaces that you implement as needed.

UserFederationProvider.getUserByUsername() and getUserByEmail() have exact equivalents in the new SPI. The difference between the two is how you import. If you are going to continue with an import strategy, you no longer call KeycloakSession.userStorage().addUser() to create the user locally. Instead you call KeycloakSession.userLocalStorage().addUser(). The userStorage() method no longer exists.

The UserFederationProvider.validateAndProxy() method has been moved to an optional capability interface, ImportedUserValidation. You want to implement this interface if you are porting your earlier provider as-is. Also note that in the earlier SPI, this method was called every time the user was accessed, even if the local user is in the cache. In the later SPI, this method is only called when the local user is loaded from local storage. If the local user is cached, then the ImportedUserValidation.validate() method is not called at all.

The UserFederationProvider.isValid() method no longer exists in the later SPI.

The UserFederationProvider methods synchronizeRegistrations(), registerUser(), and removeUser() have been moved to the UserRegistrationProvider capability interface. This new interface is optional to implement so if your provider does not support creating and removing users, you don’t have to implement it. If your earlier provider had switch to toggle support for registering new users, this is supported in the new SPI, returning null from UserRegistrationProvider.addUser() if the provider doesn’t support adding users.

The earlier UserFederationProvider methods centered around credentials are now encapsulated in the CredentialInputValidator and CredentialInputUpdater interfaces, which are also optional to implement depending on if you support validating or updating credentials. Credential management used to exist in UserModel methods. These also have been moved to the CredentialInputValidator and CredentialInputUpdater interfaces. One thing to note that if you do not implement the CredentialInputUpdater interface, then any credentials provided by your provider can be overridden locally in Keycloak storage. So if you want your credentials to be read-only, implement the CredentialInputUpdater.updateCredential() method and return a ReadOnlyException.

The UserFederationProvider query methods such as searchByAttributes() and getGroupMembers() are now encapsulated in an optional interface UserQueryProvider. If you do not implement this interface, then users will not be viewable in the admin console. You’ll still be able to log in though.

UserFederationProviderFactory versus UserStorageProviderFactory

The synchronization methods in the earlier SPI are now encapsulated within an optional ImportSynchronization interface. If you have implemented synchronization logic, then have your new UserStorageProviderFactory implement the ImportSynchronization interface.

Upgrading to a new model

The User Storage SPI instances are stored in a different set of relational tables. Keycloak automatically runs a migration script. If any earlier User Federation providers are deployed for a realm, they are converted to the later storage model as is, including the id of the data. This migration will only happen if a User Storage provider exists with the same provider ID (i.e., "ldap", "kerberos") as the earlier User Federation provider.

So, knowing this there are different approaches you can take.

  1. You can remove the earlier provider in your earlier Keycloak deployment. This will remove the local linked copies of all users you imported. Then, when you upgrade Keycloak, just deploy and configure your new provider for your realm.

  2. The second option is to write your new provider making sure it has the same provider ID: UserStorageProviderFactory.getId(). Make sure this provider is deployed to the server. Boot the server, and have the built-in migration script convert from the earlier data model to the later data model. In this case all your earlier linked imported users will work and be the same.

If you have decided to get rid of the import strategy and rewrite your User Storage provider, we suggest that you remove the earlier provider before upgrading Keycloak. This will remove linked local imported copies of any user you imported.

Stream-based interfaces

Many of the user storage interfaces in Keycloak contain query methods that can return potentially large sets of objects, which might lead to significant impacts in terms of memory consumption and processing time. This is especially true when only a small subset of the objects' internal state is used in the query method’s logic.

To provide developers with a more efficient alternative to process large data sets in these query methods, a Streams sub-interface has been added to user storage interfaces. These Streams sub-interfaces replace the original collection-based methods in the super-interfaces with stream-based variants, making the collection-based methods default. The default implementation of a collection-based query method invokes its Stream counterpart and collects the result into the proper collection type.

The Streams sub-interfaces allow for implementations to focus on the stream-based approach for processing sets of data and benefit from the potential memory and performance optimizations of that approach. The interfaces that offer a Streams sub-interface to be implemented include a few capability interfaces, all interfaces in the org.keycloak.storage.federated package and a few others that might be implemented depending on the scope of the custom storage implementation.

See this list of the interfaces that offer a Streams sub-interface to developers.

Package

Classes

org.keycloak.credential

CredentialInputUpdater(*), UserCredentialStore

org.keycloak.models

GroupModel, RoleMapperModel, UserCredentialManager, UserModel, UserProvider

org.keycloak.models.cache

CachedUserModel, UserCache

org.keycloak.storage.federated

All interfaces

org.keycloak.storage.user

UserQueryProvider(*)

(*) indicates the interface is a capability interface

Custom user storage implementation that want to benefit from the streams approach should simply implement the Streams sub-interfaces instead of the original interfaces. For example, the following code uses the Streams variant of the UserQueryProvider interface:

public class CustomQueryProvider extends UserQueryProvider.Streams {
...
    @Override
    Stream<UserModel> getUsersStream(RealmModel realm, Integer firstResult, Integer maxResults) {
        // custom logic here
    }

    @Override
    Stream<UserModel> searchForUserStream(String search, RealmModel realm) {
        // custom logic here
    }
...
}

Vault SPI

Vault provider

You can use a vault SPI from org.keycloak.vault package to write custom extension for Keycloak to connect to arbitrary vault implementation.

The built-in files-plaintext provider is an example of the implementation of this SPI. In general the following rules apply:

  • To prevent a secret from leaking across realms, you may want to isolate or limit the secrets that can be retrieved by a realm. In that case, your provider should take into account the realm name when looking up secrets, for example by prefixing entries with the realm name. For example, an expression ${vault.key} would then evaluate generally to different entry names, depending on whether it was used in a realm A or realm B. To differentiate between realms, the realm needs to be passed to the created VaultProvider instance from VaultProviderFactory.create() method where it is available from the KeycloakSession parameter.

  • The vault provider needs to implement a single method obtainSecret that returns a VaultRawSecret for the given secret name. That class holds the representation of the secret either in byte[] or ByteBuffer and is expected to convert between the two upon demand. Note that this buffer would be discarded after usage as explained below.

Regarding realm separation, all built-in vault provider factories allow the configuration of one or more key resolvers. Represented by the VaultKeyResolver interface, a key resolver essentially implements the algorithm or strategy for combining the realm name with the key (as obtained from the ${vault.key} expression) into the final entry name that will be used to retrieve the secret from the vault. The code that handles this configuration has been extracted into abstract vault provider and vault provider factory classes, so custom implementations that want to offer support for key resolvers may extend these abstract classes instead of the implementing SPI interfaces to inherit the ability to configure the key resolvers that should be tried when retrieving a secret.

For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter.

Consuming values from vault

The vault contains sensitive data and Keycloak treats the secrets accordingly. When accessing a secret, the secret is obtained from the vault and retained in JVM memory only for the necessary time. Then all possible attempts to discard its content from JVM memory is done. This is achieved by using the vault secrets only within try-with-resources statement as outlined below:

    char[] c;
    try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) {
        // ... use cSecret
        c = cSecret.getAsArray().orElse(null);
        // if c != null, it now contains password
    }

    // if c != null, it now contains garbage

The example uses KeycloakSession.vault() as the entrypoint for accessing the secrets. Using the VaultProvider.obtainSecret method directly is indeed also possible. However the vault() method has the benefit of ability to interpret the raw secret (which is generally a byte array) as a character array (via vault().getCharSecret()) or a String (via vault().getStringSecret()) in addition to obtaining the original uninterpreted value (via vault().getRawSecret() method).

Note that since String objects are immutable, their content cannot be discarded by overriding with random garbage. Even though measures have been taken in the default VaultStringSecret implementation to prevent internalizing Strings, the secrets stored in String objects would live at least to the next GC round. Thus using plain byte and character arrays and buffers is preferable.