Synchronising realm configuration between environments

Getting advice
1

We are using Keycloak 7.0.0.
We use Keycloak as part of a wider system, and therefore treat it a bit like you might a software library, deploying it locally and in QA and Live environments.
We would really like to keep the realm configuration as identical as possible between all these environments, ideally by using revision controlled files in our build system.
Exporting and importing JSON config files doesn’t seem to be an option because you lose all the users when you do this.
Manually setting values with kcadm.sh is an option, but seems a very cumbersome way of doing things.
Has anyone else had this problem, and found a useful way to fix it?

2 Likes
2

it would be nice if Keycloak had declarative config… similar to Kong (see link below)

In work, I’m currently writing a Java App which uses the Admin Java API. It’s not ideal, one failure could leave Keycloak in an inconsistent state, but it’s a step up from the kcadm.sh

We generally try to programmatically config everything… So it would be good if Keycloak was more devops friendly

https://docs.konghq.com/1.1.x/db-less-and-declarative-config/?_ga=2.130131279.1143431641.1574455082-916329250.1574455082#what-is-declarative-configuration

3

I use the keycloak-admin-client and configure my keycloak via Rest, that keeps it independant and you can have enviroment properties for your staging.

4

You can export/import users from/to Keycloak, already since the beginning.
But it’s only possible when doing it from the command line, while starting the Keycloak server.
See docs: https://www.keycloak.org/docs/latest/server_admin/index.html#_export_import

5

I’ve had a few more days working with the keycloak-admin-client - and it’s pretty bad to be honest. I have to have keycloak code open to see what’s going to happen, and even then it’s not obvious

Especially in relation to the authentication flows - it’s very very frustrating…

When I add executions to a flow, they are DISABLED by default, and I’m struggling to figure out how to enable them

2 Likes
6

@tonymurphy try this I hope it helps

    private void setExecutionToRequired(String newRealm, Keycloak keycloak, AuthenticationFlowRepresentation flowRepresentation,
                                    List<AuthenticationExecutionInfoRepresentation> executionReps, String FlowIdentifier) {
    AuthenticationExecutionInfoRepresentation resetPassword = findExecutionByProvider(FlowIdentifier, executionReps);
    resetPassword.setRequirement("REQUIRED");
    keycloak.realm(newRealm).flows().updateExecutions(flowRepresentation.getAlias(), resetPassword);
}


private AuthenticationExecutionInfoRepresentation findExecutionByProvider(String provider, List<AuthenticationExecutionInfoRepresentation> executions) {
    LOGGER.info("Provider: " + provider);
    for (AuthenticationExecutionInfoRepresentation exec : executions) {
        if (provider.equals(exec.getProviderId())) {
            return exec;
        }
    }
    return null;
}
7

So, as today there is still no reliable an easy way to share configuration among other keycloak instances?
I mean just the config, not the users.

8

Has there been any update on this request? I know this is an old topic, but i feel like this is a fairly important feature especially when used with common CD workflows.

Just to add some additional details for what i would love to see as a feature:

Realm config (including groups, clients, secrets, scopes, id providers, auth settings… everything) should be able to be exported from keycloak as a single file (no matter how complex). This configuration should be declarative (meaning that it defines a state of the system).

we should be able to then import that same config using one simple command. If the config does not already exist, it will be created. if it already exists, it will be adjusted to match the config in the file.

This allows CD pipelines to define and test their config as code then deploy to production without anyone having to use the keycloak UI to configure it.

I feel like this is almost possible with the current tools, but its not an easy one line command and usually requires parsing the config and looping through to determine if a config item already exists before either creating it or updating it.

2 Likes