[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ] arjan tijms edited comment on WFLY-4618 at 4/22/16 7:15 PM: ------------------------------------------------------------ {quote}arjan tijms have you run into this issue with your JASPIC tests?{quote} I think the issue here is that there's a confusion between whether authentication for the current request is mandatory, and whether the authentication module itself is mandatory. {code:java} Boolean.valueOf((String) messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory")); {code} This works correctly in all versions of WildFly. Per request authentication is mandatory when the resource is secured (i.e. matches a security constraint) OR when {{HttpServletRequest#authenticate}} has been called for that request. There's no problem in {{JASPIAuthenticationMechanism}} (now {{JASPICAuthenticationMechanism}}). It's explicitly specified in the JASPIC spec that an authentication module is always called for every request, whether the resource is secured or non-secured and whether the caller has been authenticated before within the same http session or not. Now the {{MessagePolicy}} is a different thing entirely. This could be used when for instance multiple authentication modules are used, which are managed by the authentication context ({{ServerAuthContext}}). The intend was here that this would function kinda like we see in PAM and JAAS, where multiple modules can be configured with REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL. *edit*: reading the spec again, I'm actually not so sure about {{MessagePolicy#isMandatory}} anymore, but I am sure about the {{MessageInfo}} variant being able to be used and working in all servers that I tested to far. I'll contact the spec lead for clarification Unfortunately, the way how multiple modules would exactly have to work together was never specified. JASPIC 1.0 put up some base infrastructure for it, but this was never really followed up on, leaving the implementation details up to the server. The spec lead explains this in some more detail here: https://java.net/jira/browse/JASPIC_SPEC-15 In practice, I haven't seen {{MessagePolicy}} used a lot. Long story short, use the {{MessageInfo}} for the property Stuart mentioned and not the method on {{MessagePolicy}}. was (Author: atijms): {quote}arjan tijms have you run into this issue with your JASPIC tests?{quote} I think the issue here is that there's a confusion between whether authentication for the current request is mandatory, and whether the authentication module itself is mandatory. {code:java} Boolean.valueOf((String) messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory")); {code} This works correctly in all versions of WildFly. Per request authentication is mandatory when the resource is secured (i.e. matches a security constraint) OR when {{HttpServletRequest#authenticate}} has been called for that request. There's no problem in {{JASPIAuthenticationMechanism}} (now {{JASPICAuthenticationMechanism}}). It's explicitly specified in the JASPIC spec that an authentication module is always called for every request, whether the resource is secured or non-secured and whether the caller has been authenticated before within the same http session or not. Now the {{MessagePolicy}} is a different thing entirely. This could be used when for instance multiple authentication modules are used, which are managed by the authentication context ({{ServerAuthContext}}). The intend was here that this would function kinda like we see in PAM and JAAS, where multiple modules can be configured with REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL. Unfortunately, the way how multiple modules would exactly have to work together was never specified. JASPIC 1.0 put up some base infrastructure for it, but this was never really followed up on, leaving the implementation details up to the server. The spec lead explains this in some more detail here: https://java.net/jira/browse/JASPIC_SPEC-15 In practice, I haven't seen {{MessagePolicy}} used a lot. Long story short, use the {{MessageInfo}} for the property Stuart mentioned and not the method on {{MessagePolicy}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)