*The key should be "javax.security.auth.message.MessagePolicy.isMandatory".
It looks like you've got a a duplicate "javax" there.*
-> Copy / paste error in the mail.
The value isn't set in Payara version that I have tested on a protected
resource. Could be a problem of JSF "Forwarding" (URL behind syndrome).
I'll check again.
On 7 May 2015 at 17:01, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>
> On Thu, May 7, 2015 at 4:15 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>
>> Thanks Arjan for some useful comments. I will have a look later on to my
>> code to update it and test again.
>>
>
> You're welcome ;)
>
>
>
>> What now happens is that when you configure a JASPIC server
>>> authentication module (programmatically or at the container level), it
>>> completely replaces the authentication method defined in web.xml. For
>>> clarity the authentication method should therefore be completely omitted
>>> from web.xml.
>>>
>>>
>> That was also what I found in my tests.
>>
>
> Yeah, so this is technically "correct", but from a usability/coherence
> point of view it's of course not ideal.
>
>
>
>
>> When a resource was called which was protected through a security
>> constraint element in the web.xml, the property __
>> "javax.javax.security.auth.message.MessagePolicy.isMandatory" isn't
>> set. So the SAM isn't aware that is is a protected resource.
>>
>
> The key should be "javax.security.auth.message.MessagePolicy.isMandatory".
> It looks like you've got a a duplicate "javax" there.
>
> There's a convenience method available via HttpMsgContext#isProtected
>
> If the resource is protected, then the
> "javax.security.auth.message.MessagePolicy.isMandatory" key is always
> present and the value if "true". However, when the resource is NOT
> protected then it depends on the server what happens. Some just omit the
> key, while others store the value "false" in that case.
>
>
>
>
>> OK, My idea was that SAM was available during the complete
>> request-response lifecycle. Wrong interpretation from my side thus.
>>
>
> The SAM itself is basically available, but the HttpMsgContext (and more
> specifically the handler that it embeds) is not directly accessible. You
> are however free to call HttpServletRequest#authenticate at any moment.
>
> So this means that unlike a javax.servlet.Filter, a SAM needs to be aware
> that it can be called *before* filters and the servlet are called, *while*
> filters and servlets are being called, and *after*. After is a separate
> method though; secureResponse. It's rare to do something there in practice.
>
> If the SAM is called explicitly (via HttpServletRequest#authenticate)
> during a request (as opposed to before) it MUST authenticate, even when the
> resource from which its called is not protected.
>
>
>
> What you can do however is *trigger* authentication by calling
>>> HttpServletRequest#authenticate. You can do this at any moment during
>>> request processing. This will result in the SAM(s) that you have configured
>>> being called. From the SAM you then use HttpMsgContext.
>>>
>>> HttpServletRequest#authenticate who triggers the SAM is something that I
>> wel need to check.
>> My idea was that the SecurityContext looked up the IdentityStore and
>> interacts directly with it.
>>
>
> The lookup of the identity store is something which has not been specified
> at all by any party yet. A SAM represents the authentication mechanism, not
> the identity store.
>
> If you would do it totally in user code now then the container would not
> be aware of the login, and things like @RolesAllowed and
> request.isUserInRole (and variants) would not work any more.
>
> There's only 1 API in Java EE that is capable of communicating
> authentication data to the container now and that is JASPIC. See
> https://wiki.shibboleth.net/confluence/display/SHIB2/Java+EE+Container-Managed+Authentication
> for a rather good write up about some of the core concepts.
>
> You can now, using standard APIs, build on this by having an optional SAM
> that "does nothing" except looking up the identity store, putting in the
> credentials, getting the username/roles back and communicating those to the
> container.
>
> It's an open question of how to handle the identity store only login.
>
> With a standardized identity store, HttpServletRequest#login could be
> specified as calling through to that, but then the next request the
> authentication data would have to be retrieved from somewhere (e.g. the
> session) and re-applied. This is where a "do nothing" SAM would come in
> again anyway. Meaning, we might not need a new mechanism/API to communicate
> those details to the container, just a standard implementation of a SAM for
> this purpose, the availability of CDI and specifying that CDI is used to
> retrieve the identity store (with a specific bean type and/or specific
> annotations etc).
>
>
>
> not-ideal -> Would call it an issue.
>>
>
> Indeed, issue https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12 to be
> exact ;)
>
> As explained in the comments of that, JAVAEE_SECURITY_SPEC-12 is intended
> first and fore all to align the 4 different ways that exist now in Java EE
> to get the user/caller principal.
>
> For some reason it has been interpreted as a new way to communicate
> authentication data to the container, but that's really not the idea. It's
> supposed to just wrap existing APIs, and where needed make sure some of the
> underlying APIs are better specified.
>
> A platform specific implementation of it *may* compensate for container
> differences in the underlying API. E.g. a GlassFish implementation could
> use knowledge about what in GlassFish the EJB specific representation of
> the unauthenticated identity is, and translate that to a null. Whether this
> is the way is still open for discussion of course, but it may be a
> relatively easy solution to do it this way.
>
> Kind regards,
> Arjan
>
>
>