Details
-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
7.4.7.GA
-
None
-
False
-
None
-
False
Description
In short: JBoss 7.4..7 with elytron security enforces its basic authentication (unwanted/ unconfigured) when seeing the "Authorization" http header and rejects them, whilst they should be passed directly to our app.
We have a JEE 8 web application containing our own logic for basic authentication implemented directly in this application (we just read "Authorization" http header and act upon).
Security is not configured in the web.xml. We do not want to use container authentication.
It works fine with Wildfly 26.1.2 (using default elytron security and java 8, 11, 17) and JBoss 7.4.7 (using default legacy security and java 8, 11) but not for JBoss 7.4.7 with elytron security (required when using java 17; conversion done using jboss enable-elytron-se17.cli suggested in Knowledgebase: https://access.redhat.com/articles/6956863).
After conversion JBoss 7.4.7 to elytron security we can make following observations:
- requests without "Authorization" header are passed to our application
- requests with "Authorization" header (with credentials of our users) are rejected ("Unauthorized") by JBoss
- requests with "Authorization" header (with credentials of jboss users) are passed to our application (where we reject them due to wrong credentials).
It looks that when JBoss sees a request with "Authorization" header it tries to do its own default authentication for such a request regardless whether such authorization is configured in the descriptors of the application. An excerpt from curl output for a call with credentials of our users:
* HTTP/2 found, allow multiplexing
< HTTP/2 401
< www-authenticate: Basic realm="localhost:8443"
We checked that removing the "other" application-security-domain from undertow subsystem:
<application-security-domains> <application-security-domain name="other" security-domain="ApplicationDomain"/> </application-security-domains>
might be a workaround (not sure what the other side effects are), but for us it is not acceptable as we also use client certificate authentication (like in this example https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.4.x/helloworld-mutual-ssl; defined on a separate listener) and this authentication stops working due to not getting the certificate details. It is reproducible with mentioned quickstart, where we get:
java.lang.RuntimeException: No X.509 client certificate found in request at org.jboss.as.quickstarts.helloworld.HelloWorldServlet.extractCertificate(HelloWorldServlet.java:69) at org.jboss.as.quickstarts.helloworld.HelloWorldServlet.doGet(HelloWorldServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:503) at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
Wildfly 26.1.2 having the same configuration regarding "other" application-security-domain in undertow subsystem works as expected (passes all the requests to our application without enforcing its authentication).