Securing web applications with Keycloak and CLI

MENU

Keycloak is a great open-source authentication (now also authorization/access control) server particularly suited for applications consisting of many (micro)services. To make it easier to secure applications on WildFly and other runtimes, Keycloak comes with OpenID Connect and SAML 2.0 adapters. More information on adapter installation and configuration can be found in Keycloak’s documentation.

WildFly adapter offers you 2 ways of securing your WARs – you can bundle the configuration with your application (via a keycloak.json file under your application’s WEB-INF directory), or you can secure your WAR externally using the Keycloak subsystem (in the configuration file of your server, e.g. standalone.xml). Although the former is convenient and I am a fan of keeping configuration with the application code in general, I prefer to use the latter because of its flexibility – you don’t need to modify your WAR files depending on where you deploy them, you can use the same bundles on your local development instance and in production.

The XML snippet needed to configure the subsystem is easy to obtain - you can download it through Keycloak Admin Console (select Keycloak OIDC JBoss subsystem XML under your client application’s Installation tab). Depending on your setup, the configuration will be similar to this (the realm key has been ellipsized for brevity):

400: Invalid request

However, if you prepare your server in an automated way, e.g. through a Dockerfile, your configuration changes often, or you have many WAR files to secure, JBoss CLI is a better option. The rest of this post shows how to replicate the configuration above with CLI.

We start by setting up the realm configuration:

400: Invalid request

The disable-trust-manager option disables verification of SSL certificates. As such, it should never be used in production. For development purposes, you could also disable the requirement for secure communication completely:

400: Invalid request

In production, however, you should keep the requirement for SSL for all communication, and provide the relevant keystore file, e.g.: