How we struggled with the WildFly 23 to WildFly 26 Upgrade

What

Hogarama (Home and Garden Automation) is one of our Learning Friday projects where we can experiment with all kinds of technologies. Since the system somehow got out of bounds, we planned to simplify the architecture. This is, however, an another story for another day. Besides, we also decided to bring the application from WildFly 23 to the latest (26.1.1) WildFly version and this is the story for today.

Elytron Subsystem

Since we are notoriously lazy people, we still used the (now legacy) security subsystem. Wildfly 26 doesn’t support the old security subsystem anymore, so we knew we had to switch to the Elytron subsystem for security configuration.

Keycloak

We use Keycloak as an SSO server for Hogarama. In WildFly 23 and earlier we configured this in a login module in standalone.xml

<security-domain name="keycloak">
     <authentication>
       <login-module             
          code="org.keycloak.adapters.jboss.KeycloakLoginModule" 
          flag="required"/>
     </authentication>
   </security-domain>

and in web.xml

<login-config>
        <auth-method>KEYCLOAK</auth-method>
</login-config>

Additionally we had to install the keycloak module in WildFly.

In our application we use three different endpoints that relate to Keycloak

1. A web page admin.html where the browser has to authenticate to the WildFly server
2. An Angular/Ionic client application where the client authenticates with Keycloak
3. REST services where the client sends a Bearer token to the WildFly server to authenticate

Light and Shadows

We set up all our JBoss servers with jboss-cli and JBSS. Generally it’s not a big deal to switch from one WildFly version to another. Also this time we had no issues except with the security subsystem.

On the excellent Mastertheboss site we found how to use OpenId Connect (OIDC) with WildFly. This is supported by WildFly 26 by default, no additional modules and no Keycloak subsystem is needed. That is really nice. Just use 

<login-config>
        <auth-method>OIDC</auth-method>
    </login-config>

in web.xml and instead of keycloak.json use oidc.json:

{
  "client-id" : "${env.KEYCLOAK_CLIENT_ID}",
  "provider-url":
      "${env.KEYCLOAK_AUTH_SERVER_URL}/realms/${env.KEYCLOAK_REALM}",
  "ssl-required": "external",
  "credentials": {"secret":"${env.KEYCLOAK_CREDENTIALS_SECRET}"},
  "disable-trust-manager":true,
  "allow-any-hostname": true
}

With these changes we could login on the admin.html. However, authentication with REST didn’t work. Our Angular client always got a CORS-Error in the Browser. It turned out that Bearer authentication did not work with OIDC, probably because of WFLY-15485, which was not fixed in WildFly 26.1.1. To the rescue came Microprofile JSON Web Token which is also supported by WildFly 26. In our REST module we configured

<login-config>
        <auth-method>MP-JWT</auth-method>
</login-config>

in web.xml and in microprofile-config.properties:

mp.jwt.verify.publickey.location=${KEYCLOAK_AUTH_SERVER_URL}/realms/${KEYCLOAK_REALM}/protocol/openid-connect/certs
mp.jwt.verify.issuer=${KEYCLOAK_AUTH_SERVER_URL}/realms/${KEYCLOAK_REALM}

That fixed the authentication with Bearer Token.

Conclusion

At the end we use OIDC for browser logins and JWT for Bearer token login. Both are standard and have no Keycloak dependencies. No special configuration in standalone.xml is needed. Hogarama is watering our plants again, the sun is shining, bees are humming  and life is generally good.