javawildflyejb-3.0elytronjacc

Wildlfy 26: java.lang.IllegalArgumentException: unknown handler key at javax.security.jacc.api


I am trying to upgrade a monolith application from Wildfly 23 to Wildfly 26.

Originally the application used a dummy configuration of "jaspitest" in the standalone.xml

Old Config for security

 <subsystem xmlns="urn:jboss:domain:security:2.0">
            <security-domains>
                <security-domain name="other" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="RealmDirect" flag="required">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>
                <security-domain name="jboss-web-policy" cache-type="default">
                    <authorization>
                        <policy-module code="Delegating" flag="required"/>
                    </authorization>
                </security-domain>
                <security-domain name="jaspitest" cache-type="default">
                    <authentication-jaspi>
                        <login-module-stack name="dummy">
                            <login-module code="Dummy" flag="optional"/>
                        </login-module-stack>
                        <auth-module code="Dummy"/>
                    </authentication-jaspi>
                </security-domain>
                <security-domain name="jboss-ejb-policy" cache-type="default">
                    <authorization>
                        <policy-module code="Delegating" flag="required"/>
                    </authorization>
                </security-domain>
            </security-domains>
        </subsystem>

Under guidance from the Wildfly migration guide - Migration Guide

This is now expressed as such in the new Wildfly 26 config

<application-security-domains>
     <application-security-domain name="jaspitest" security-domain="ApplicationDomain" enable-jaspi="false">
     </application-security-domain>
</application-security-domains>

Full (redacted) config is here - https://pastebin.com/kEM5gN3C

Jboss-xml

<jboss-web>
    <security-domain>jaspitest</security-domain>
    <context-root>/</context-root>
    <resource-ref>
        <res-ref-name>jsf/ProjectStage</res-ref-name>
        <jndi-name>java:/env/jsf/ProjectStage</jndi-name>
    </resource-ref>
</jboss-web>

This configuration is working for unsecured pages on the web application, however trying to login using a JSF login page.

It throws this FATAL error:

10:04:17,518 FATAL [uk.co.xxxxxxx.exception.CustomExceptionHandler] (default task-5) [id=2820080d-1642-45d2-9de7-b1e527262bc7, ip=172.28.0.1, url=/parents/login/, user=null, params={form=form, form:email:input=bruce.taylor@xxxxxxx.co.uk, form:loginWithPassword=********, form:password:input=********, javax.faces.partial.ajax=true, javax.faces.partial.execute=@all, javax.faces.partial.render=login, javax.faces.source=form:loginWithPassword}]: java.lang.IllegalArgumentException: unknown handler key
2022-02-10T10:04:17.520512634Z  at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.PolicyContext.getContext(PolicyContext.java:223)
2022-02-10T10:04:17.520519816Z  at org.glassfish.soteria@1.0.1-jbossorg-1//org.glassfish.soteria.authorization.JACC$2.run(JACC.java:151)
2022-02-10T10:04:17.520523921Z  at java.base/java.security.AccessController.doPrivileged(Native Method)
2022-02-10T10:04:17.520527172Z  at org.glassfish.soteria@1.0.1-jbossorg-1//org.glassfish.soteria.authorization.JACC.getFromContext(JACC.java:149)
2022-02-10T10:04:17.520530561Z  at org.glassfish.soteria@1.0.1-jbossorg-1//org.glassfish.soteria.authorization.JACC.getSubject(JACC.java:49)
2022-02-10T10:04:17.520533842Z  at org.glassfish.soteria@1.0.1-jbossorg-1//org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.getCallerPrincipal(ReflectionAndJaccCallerDetailsResolver.java:33)
2022-02-10T10:04:17.520537741Z  at org.glassfish.soteria@1.0.1-jbossorg-1//org.glassfish.soteria.SecurityContextImpl.getCallerPrincipal(SecurityContextImpl.java:55)
2022-02-10T10:04:17.520549561Z  at deployment.xxxxxxx.war//uk.co.xxxxxxx.security.Authenticator.authenticate(Authenticator.java:340)
2022-02-10T10:04:17.520553467Z  at deployment.xxxxxxx.war//uk.co.xxxxxxx.security.Authenticator.authenticateWithFacesContext(Authenticator.java:311)
2022-02-10T10:04:17.520557396Z  at deployment.xxxxxxx.war//uk.co.xxxxxxx.security.Authenticator.loginAndRedirect(Authenticator.java:293)
2022-02-10T10:04:17.520561301Z  at deployment.xxxxxxx.war//uk.co.xxxxxxx.security.Authenticator$Proxy$_$$_WeldClientProxy.loginAndRedirect(Unknown Source)
2022-02-10T10:04:17.520565505Z  at deployment.xxxxxxx.war//uk.co.xxxxxxx.backing.LoginBacking.loginWithPassword(LoginBacking.java:112)
2022-02-10T10:04:17.520569536Z  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2022-02-10T10:04:17.520574368Z  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
2022-02-10T10:04:17.520578603Z  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2022-02-10T10:04:17.520582207Z  at java.base/java.lang.reflect.Method.invoke(Method.java:566)
2022-02-10T10:04:17.520585425Z  at javax.el.api@2.0.0.Final//javax.el.ELUtil.invokeMethod(ELUtil.java:245)

A google search shows this error relating to other Application servers like TomEE etc.

Things I have done:

Archtecture

The codebase has :

It explodes when calling the injected bean of SecurityContext getCallerPrinciple()

enter image description here

As a non-Java EE person, it would be helpful to understand what is actually going on and get pointed in the direction of how to fix this?

I don't understand why I need JACC though, there is no Authorization requirements in the existing monolith.


Solution

  • Try in cli:

    /subsystem=elytron/policy=jacc:add(jacc-policy={})