[
https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin....
]
Eric Wittmann commented on WFLY-4304:
-------------------------------------
I ran into this issue in apiman a couple months ago, and worked around it by splitting my
app into two separate WARs. It would have been much better to not have to do that,
though. :) Here is my original post to the KC mailing list:
----
In apiman I have a bit of an edge case that currently isn't working as I was hoping
(running in wildfly 8.2 - not tested on any other platform).
The issue is that I have a WAR with two sub-contexts:
/api - JAX-RS endpoints to configure the API Gateway
/gateway - the API Gateway (reverse proxy)
I wanted /api to be protected by keycloak, but for /gateway to be unprotected.
My web.xml looks like this:
{code}
<security-constraint>
<web-resource-collection>
<web-resource-name>apiman-gateway</web-resource-name>
<url-pattern>/api/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>apiadmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>apiman</realm-name>
</login-config>
<security-role>
<role-name>apiadmin</role-name>
</security-role>
{code}
It all works great until I send a request to /gateway/* that includes an
"Authorization" http header. If I do that, the adapter tries to authenticate
with those credentials and fails with a 401 if they don't match (which they
don't).
I realize this is an odd case, but I did expect that if the web.xml specified that only
/api/* were protected then other paths would simply pass through any Authorization
headers. That may be an incorrect expectation - not sure what the servlet spec requires
in this case.
The use-case here is that the Gateway servlet itself supports all sorts of authentication
policies (BASIC auth, certificates, OAuth, SAML, etc etc). It all depends on the
configuration of the API being called (the gateway proxies requests to back-end API
implementations).
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)