A Testcontainers implementation for Keycloak SSO.
This version branch (3.x) only handles Keycloak from version 22.x and up, as there are major changes coming with this release (see the blog post).
See also compatibility matrix.
For older Keycloak versions (until 21.x), see version 2.x branch.
The @Container
annotation used here in the readme is from the JUnit 5 support of Testcontainers.
Please refer to the Testcontainers documentation for more information.
Simply spin up a default Keycloak instance:
@Container
KeycloakContainer keycloak = new KeycloakContainer();
Use another Keycloak Docker image/version than used in this Testcontainer:
@Container
KeycloakContainer keycloak = new KeycloakContainer("quay.io/keycloak/keycloak:26.0");
Use different admin credentials than the default internal (admin
/admin
) ones:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withAdminUsername("myKeycloakAdminUser")
.withAdminPassword("tops3cr3t");
Power up a Keycloak instance with one or more existing realm JSON config files (from classpath):
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withRealmImportFile("/test-realm.json");
or
.withRealmImportFiles("/test-realm-1.json", "/test-realm-2.json");
If your realm JSON configuration file includes user definitions - particularly the admin user for the master realm - ensure you disable the automatic bootstrapping of the admin user:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withBootstrapAdminDisabled()
.withRealmImportFile("/test-realm.json");
To retrieve a working Keycloak Admin Client from the container, make sure to override the admin credentials to match those in your imported realm JSON configuration file:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withBootstrapAdminDisabled()
.withRealmImportFile("/test-realm.json")
.withAdminUsername("myKeycloakAdminUser")
.withAdminPassword("tops3cr3t");
You can get an instance of org.keycloak.admin.Keycloak
admin client directly from the container, using
org.keycloak.admin.Keycloak keycloakAdmin = keycloakContainer.getKeycloakAdminClient();
The admin client is configured with current admin credentials.
The
org.keycloak:keycloak-admin-client
package is now a transitive dependency of this project, ready to be used by you in your tests, no more need to add it on your own.
You can also obtain several properties from the Keycloak container:
String authServerUrl = keycloak.getAuthServerUrl();
String adminUsername = keycloak.getAdminUsername();
String adminPassword = keycloak.getAdminPassword();
with these properties, you can create e.g. a custom org.keycloak.admin.client.Keycloak
object to connect to the container and do optional further configuration:
Keycloak keycloakAdminClient = KeycloakBuilder.builder()
.serverUrl(keycloak.getAuthServerUrl())
.realm(KeycloakContainer.MASTER_REALM)
.clientId(KeycloakContainer.ADMIN_CLI_CLIENT)
.username(keycloak.getAdminUsername())
.password(keycloak.getAdminPassword())
.build();
As Keycloak comes with the default context path /
, you can set your custom context path, e.g. for compatibility reasons to previous versions, with:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withContextPath("/auth");
Starting from Keycloak version 25.0.0, Keycloak will propagate /health
and /metrics
on "Management Port", see Configuraing the Management Interface and Migration Guide
KeycloakContainer keycloak = new KeycloakContainer().withEnabledMetrics()
keycloak.start();
keycloak.getMgmtServerUrl();
As of Keycloak 24 the container doesn't use an absolute amount of memory, but a relative percentage of the overall available memory to the container, see also here.
This testcontainer has an initial memory setting of
JAVA_OPTS_KC_HEAP="-XX:InitialRAMPercentage=1 -XX:MaxRAMPercentage=5"
to not overload your environment.
You can override this settng with the withRamPercentage(initial, max)
method:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withRamPercentage(50, 70);
You have three options to use HTTPS/TLS secured communication with your Keycloak Testcontainer.
This Keycloak Testcontainer comes with built-in TLS certificate (tls.crt
), key (tls.key
) and Java KeyStore (tls.jks
) files, located in the resources
folder.
You can use this configuration by only configuring your testcontainer like this:
@Container
KeycloakContainer keycloak = new KeycloakContainer().useTls();
The password for the provided Java KeyStore file is changeit
.
See also KeycloakContainerHttpsTest.shouldStartKeycloakWithProvidedTlsKeystore
.
The method getAuthServerUrl()
will then return the HTTPS url.
Of course you can also provide your own certificate and key file for usage in this Testcontainer:
@Container
private KeycloakContainer keycloak = new KeycloakContainer()
.useTls("your_custom.crt", "your_custom.key");
See also KeycloakContainerHttpsTest.shouldStartKeycloakWithCustomTlsCertAndKey
.
The method getAuthServerUrl() will also return the HTTPS url.
Last but not least, you can also provide your own keystore file for usage in this Testcontainer:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.useTlsKeystore("your_custom.jks", "password_for_your_custom_keystore");
See also KeycloakContainerHttpsTest.shouldStartKeycloakWithCustomTlsKeystore
.
The method getAuthServerUrl()
will also return the HTTPS url.
You can enable and disable features on your Testcontainer:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withFeaturesEnabled("docker", "scripts", "...")
.withFeaturesDisabled("authorization", "impersonation", "...");
All default configurations in this Testcontainer is done through environment variables. You can overwrite and/or add config settings on command-line-level (cli args) with this method:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withCustomCommand("--hostname=keycloak.local");
A warning will be printed to the log output when custom command parts are being used, so that you are aware that you are responsible on your own for proper execution of this container.
By default, the container is started in dev mode (start-dev
).
If needed you can enable production mode:
@Container
KeycloakContainer keycloak = new KeycloakContainer()
.withProductionMode();
To ease extension testing, you can tell the Keycloak Testcontainer to detect extensions in a given classpath folder. This allows to test extensions directly in the same module without a packaging step.
If you have your Keycloak extension code in the src/main/java
folder, then the resulting classes will be generated to the target/classes
folder.
To test your extensions you just need to tell KeycloakContainer
to consider extensions from the target/classes
folder.
Keycloak Testcontainer will then dynamically generate a packaged jar file with the extension code that is then picked up by Keycloak.
KeycloakContainer keycloak = new KeycloakContainer()
.withProviderClassesFrom("target/classes");
For your convenience, there's now (since 3.3) a default method, which yields to target/classes
internally:
KeycloakContainer keycloak = new KeycloakContainer()
.withDefaultProviderClasses();
See also KeycloakContainerExtensionTest
class.
If you need to provide any 3rd-party dependency or library, you can do this with
List<File> libs = ...;
KeycloakContainer keycloak = new KeycloakContainer()
.withProviderLibsFrom(libs);
You have to provide a list of resolvable File
s.
In case you need a custom implementation of the default KeycloakContainer
, you should inherit from ExtendableKeycloakContainer
. This allows to set the generics and use your custom implementation without the need for type casts.
public class MyCustomKeycloakContainer extends ExtendableKeycloakContainer<MyCustomKeycloakContainer> {
public MyCustomKeycloakContainer() {
super();
}
public MyCustomKeycloakContainer(String dockerImageName) {
super(dockerImageName);
}
}
...
MyCustomKeycloakContainer keycloakContainer = new MyCustomKeycloakContainer()
.withAdminPassword("password");
If you want/need to use dependencies from e.g. Maven (or Gradle), you can use ShrinkWrap Resolvers.
See, as an example, how this is used at the KeycloakContainerExtensionTest#shouldDeployProviderWithDependencyAndCallCustomEndpoint()
test.
You can tell the Keycloak Testcontainer to open a debug port for attaching a remote debugger.
This command will enable remote debugging in Keycloak and expose the used debug port in the container on a random port to the outside:
KeycloakContainer keycloak = new KeycloakContainer()
.withDebug();
If you want to enable remote debugging on a fixed port and optionally have Keycloak wait (suspend) until a debugger has attached to this port, use this command:
KeycloakContainer keycloak = new KeycloakContainer()
.withDebugFixedPort(int hostPort, boolean suspend);
The release versions of this project are available at Maven Central.
Simply put the dependency coordinates to your pom.xml
(or something similar, if you use e.g. Gradle or something else):
<dependency>
<groupId>com.github.dasniko</groupId>
<artifactId>testcontainers-keycloak</artifactId>
<version>VERSION</version>
<scope>test</scope>
</dependency>
The testcontainers project itself has a dependency on JUnit4 although it is not needed for this project in order to run (see this issue for more details).
To avoid pulling in JUnit4 this project comes with a dependency on the quarkus-junit4-mock
library which includes all needed classes as empty stubs. If you need JUnit4 in your project you should exclude this mock library
when declaring the dependency to testcontainers-keycloak
to avoid issues. Example for maven:
<dependency>
<!-- ... see above -->
<exclusions>
<exclusion>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit4-mock</artifactId>
</exclusion>
</exclusions>
</dependency>
This info is not specific to the Keycloak Testcontainer, but using Testcontainers in general.
I mention it here, as I see people asking again and again on how to use it in their test setup, when they think they need to specify a fixed port in their properties or YAML files...
You don't have to!
But you have to read the Testcontainers docs and the docs of your application framework on testing resources!!
Dynamic context configuration with context initializers is your friend.
In particular, look for @ContextConfiguration
and ApplicationContextInitializer<ConfigurableApplicationContext>
:
- https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#spring-testing-annotation-contextconfiguration
- https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#testcontext-ctx-management-initializers
Read the docs about the Quarkus Test Resources and use @QuarkusTestResource
with QuarkusTestResourceLifecycleManager
Consult the docs of your application framework testing capabilities on how to dynamically configure your stack for testing!
For Keycloak versions until 21.x, see version 2.x branch
Testcontainers-Keycloak | Testcontainers | Keycloak |
---|---|---|
3.0.x | 1.18.3 | 22.0 |
3.1.x | 1.18.3 | 22.0.5 |
3.2.x | 1.19.3 | 23.0 |
3.3.x | 1.19.6 | 24.0 |
3.4.x | 1.19.8 | 25.0 |
3.5.x | 1.20.2 | 26.0 |
There might also be other possible version configurations which will work.
See also the Releases page for version and feature update notes.
Many thanks to the creators and maintainers of Testcontainers. You do an awesome job!
Same goes to the whole Keycloak team!
Kudos to @thomasdarimont for some inspiration for this project.
Apache License 2.0
Copyright (c) 2019-2024 Niko Köbler
See LICENSE file for details.