[
https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin....
]
Eric Wittmann commented on WFLY-4304:
-------------------------------------
I haven't specifically tested this, but the assumption is that this same problem would
occur without Keycloak in the loop (just using standard BASIC authentication with JAAS).
The response from the KC mailing list:
"Its really a problem with wildfly, not keycloak. Keycloak just implements the auth
SPI of wildfly."
Which seems reasonable. :)
Servlet authentication kicked off when *not* a part of any
security-constraint
------------------------------------------------------------------------------
Key: WFLY-4304
URL:
https://issues.jboss.org/browse/WFLY-4304
Project: WildFly
Issue Type: Bug
Affects Versions: 8.2.0.Final
Reporter: Brett Meyer
Assignee: Jason Greene
Priority: Critical
Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet
that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to
authenticate the call (using Wireshark, I see the GET/POST get funneled through the
Keycloak realm redirection) if basic auth credentials are in the header. In a
keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue
within Wildfly auth itself.
A credentialed call on an un-protected servlet does sound like an edge case. However,
this came up possibly due to a secondary symptom:
If I protect the servlet in web.xml, the call's Authorization header is stripped.
I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)