Writing Keycloak extensions: Key concepts and anti-patterns

Keycloak comes preconfigured with a number of industry-standard providers, themes, and connectors. These built-in features are fairly robust, but they may not always be sufficient. To implement custom features, Keycloak allows you to use a number of service provider interfaces (SPI). By extending them, you can add a new social identity provider or make a unique form action to tell the difference between human and automated access.

Key concepts

There are two fundamental components that make up a custom Keycloak service provider: a ProviderFactory and the actual Provider itself.

ProviderFactory

As implied by its name, the ProviderFactory is the component that is in charge of actually creating the Provider. The factory will be discovered once the Keycloak server is launched, and only one instance of it will exist for the duration of the server's operation. Its interface, limited to the essential bits, is as follows:

public interface ProviderFactory<T extends Provider> {

    void init(Config.Scope config);

    void postInit(KeycloakSessionFactory factory);

    void close();

    T create(KeycloakSession session);

    // not mentioned: getId, order, getConfigMetadata

}

Now, let's examine each method in greater depth.

void init(Config.Scope config)

During the initialization of the factory, init will be called once and only once. The configuration will be obtained from the keycloak_server.json file. You can use this method to initialize and create objects that will be utilized in your implementation of the provider. To illustrate, HTTP clients and database clients are two examples of objects that should almost never be created more than once.

void postInit(KeycloakSessionFactory factory)

After all provider factories have been initialized, the function postInit will be invoked. You can now access any additional ProviderFactories and SPIs that you require. Further more, if your business logic calls for it, you might also initialize recurring tasks.

void close()

The close method is called when the server shuts down. Resources, such as HTTP clients, created in the init or postInit methods should be released here.

T create(KeycloakSession session)

This is the method that creates the actual provider instance. Keycloak is calling this method on each request so the provider object itself should be light-weight.

Provider

Each time a request is made, Keycloak invokes the create function on the ProviderFactory to generate a new provider object. In the provider, you'll implement the business logic of the functionality you want to add to your system. The only truly essential part of the interface is the close method, which frees up any resources that were allocated for the request but are no longer in use. Other methods will depend on the actual provider interface you want to implement.

Provider discorvery

To tell Keycloak where to find the ProviderFactory, you have to set up a file in META-INF/services named after the specific service provider implementation and the fully qualified name of your service ProviderFactory as the file content.

Anti-Patterns

Having covered the fundamentals of what a custom provider should look like, we can now examine bad practices that may arise while developing a Keycloak extension.

AP#1 - Implementing ProviderFactory and Provider in the same class

Take a look at the following example, in which a ProviderFactory and a Provider are implemented in the same class.

class AntiPatternProvider implements ProviderFactory<AntiPatternProvider>, Provider {

    private HTTPClient httpClient;

    @Override
    public AntiPatternProvider create(KeycloakSession session) {
        httpClient.post("https://example.com");

        return this;
    }

    @Override
    public void init() {
        httpClient = new HTTPClient();
    }

    @Override
    public void close() {
        httpClient.close();
    }

    // other implementation specific functions...
}

Yes, it would appear odd, but in theory, this is a legitimate provider. Can you identify any potential issues?

The server will start up without any problems, but as soon as the provider receives a second request, an error message stating that the HTTP client has already been closed will appear. Keycloak has no means of knowing that we only want to close the HTTP client when the server is shutting down. Instead, each request will result in the client closing. This is because we are implementing the close method of both the ProviderFactory and the Provider, which, as we have seen, have different responsibilities.

We can avoid the issue by implementing the Provider and the ProviderFactory in separate classes.

class BestPracticeProvider implements Provider {

    private final HTTPClient httpClient;

    public BestPracticeProvider(HTTPClient httpClient) {
        this.httpClient = httpClient;
    }

    @Override
    public void close() {
        // This method will be called on each request. 
        // Do not close the HTTP client here!
    }
}

class BestPracticeProviderFactory implements ProviderFactory<BestPracticeProvider> {

    private HTTPClient httpClient;

    @Override
    public BestPracticeProvider create(KeycloakSession session) {
        return new BestPracticeProvider(httpClient);
    }

    @Override
    public void init() {
        httpClient = new HTTPClient();
    }

    @Override
    public void close() {
        // The server is shutting down. 
        // We can safely close the HTTP client.
        httpClient.close();
    }

    // other implementation specific functions...
}

AP#2 - Creating heavy-weight objects during requests

In the example below, we will look at another anti-pattern that may arise while creating a provider.

class AntiPatternProvider implements Provider {

    private final HTTPClient httpClient;

    public AntiPatternProvider() {
        httpClient = new HTTPClient();
    }

    @Override
    public void close() {
        httpClient.close();
    }
}

class AntiPatternProviderFactory implements ProviderFactory<AntiPatternProvider> {

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

    // other implementation specific functions...
}

In this provider implementation, the HTTP client is created and closed during each request. The issue is that the client is a heavy object. Creating it for every request is expensive. Similarly to how we fixed AP#1, we need to have the ProviderFactory handle both the creation and closing of the HTTP client.

Conclusion

Keycloak offers a lot of possibilities to extend its built-in functionality. Anyone working on an extension should familiarize themselves with the Keycloak SPI first. In my opinion, Keycloak's documentation and examples aren't great, especially for developers who are just getting started.

So, here are a few general recommendations when you are starting out:

• Treat each provider as a self-contained application.
• Keep an eye out for resources that have to be released once the server is shut down or the request is finished. Otherwise, you may unintentionally create memory leaks.
• Avoid having multiple providers in the same library whenever possible. Instead, try to split them up per domain. This will make it easier to test, maintain, and deploy them.
• Keep your providers up to date with the latest Keycloak version.
• Do not package external libraries with shadowJar (only applies to the Quarkus distribution). Instead, add the libraries to the providers directory.

Thank you for reading

Do you have any questions? Was this article helpful? Let me know in the comments below.