Keycloak has a separate adapter for Jetty 9.1.x and Jetty 9.2.x that you will have to install into your Jetty installation. You then have to provide some extra configuration in each WAR you deploy to Jetty. Let's go over these steps.

There is a adapter zip file for Jetty 9.x in the adapters/ directory in the Keycloak appliance or war distribution. Depending on your version of Jetty, you must unzip this file into Jetty's root directory. Including adapter's jars within your WEB-INF/lib directory will not work! $ cd $JETTY_HOME $ unzip keycloak-jetty92-adapter-dist.zip Next, you will have to enable the keycloak module for your jetty.base. $ cd your-base $ java -jar $JETTY_HOME/start.jar --add-to-startd=keycloak

This section describes how to secure a WAR directly by adding config and editing files within your WAR package. The first thing you must do is create a WEB-INF/jetty-web.xml file in your WAR package. This is a Jetty specific config file and you must define a Keycloak specific authenticator within it. ]]> Next you must create a keycloak.json adapter config file within the WEB-INF directory of your WAR. The format of this config file is describe in the general adapter configuration section. The Jetty 9.1.x adapter will not be able to find the keycloak.json file. You will have to define all adapter settings within the jetty-web.xml file as described below. Instead of using keycloak.json, you can define everything within the jetty-web.xml. You'll just have to figure out how the json settings match to the org.keycloak.representations.adapters.config.AdapterConfig class. tomcat customer-portal http://localhost:8081/auth external MIGfMA0GCSqGSIb3DQEBAQUAA4 ]]> You do not have to crack open your WAR to secure it with keycloak. Instead create the jetty-web.xml file in your webapps directory with the name of yourwar.xml. Jetty should pick it up. In this mode, you'll have to declare keycloak.json configuration directly within the xml file. Finally you must specify both a login-config and use standard servlet security to specify role-base constraints on your URLs. Here's an example: customer-portal Customers /* user /* CONFIDENTIAL BASIC this is ignored currently/realm-name> admin user ]]>