[jboss-jira] [JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint

[Darran Lofthouse (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050345#comment-13050345 ] 

Darran Lofthouse commented on WFLY-4304:
----------------------------------------

If you are looking into this issue keep in mind that authenticating when we receive a challenge response is a deliberate design decision - some mechanisms will not work correctly if we ignore these headers.

Having said that we did previously have a config option within Undertow to control the behaviour so maybe that just needs exposing for the subsystem.

Please only work on this issue if you are sure you are going to get this in for WildFly 9 as for WildFly 10 there are plenty of changes in this area.

> 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: Tomas Hofman
>
> 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)