[jboss-jira] [JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources

[arjan tijms (JIRA)]

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

arjan tijms commented on WFLY-4618:
-----------------------------------

[~stuartdouglas] I did some initial research looking at actual SAM implementations for companies I worked for (closed source, but very practical) and open source ones, and almost none really use {{MessagePolicy}}. I found 1 that uses it as an alternative to {{messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory"))}}. See https://github.com/arjantijms/cas-jaspic/blob/master/src/main/java/com/googlecode/cas/jaspic/servlet/CasServerAuthModule.java

Interestingly, I also found an existing discussion regarding early JASPIC support in WildFly, where one participant had the exact same idea about the {{MessagePolicy}}:

{quote}
Spec 3.8.1.1 seems pretty unambigious to me on setting the property.
It is worth noting, that there are actually two different isMandatory flags in play:
The one passed in the MessageInfo arguement to SAM.validateRequest tells if this particular request is accessing a protected resource, while the other is passed to SAM.initialize in the requestPolicy argument, that is analogous to the JAAS auth module required/optional flag.
{quote}

See https://github.com/wildfly/wildfly/pull/5558

So at least it seems a somewhat common confusion. To be continued.

> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
>                 Key: WFLY-4618
>                 URL: https://issues.jboss.org/browse/WFLY-4618
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.2.0.Final, 9.0.0.CR1
>            Reporter: Gernot Müller
>            Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)