Hi,
On Thursday, May 7, 2015, Rudy De Busscher <rdebusscher_at_gmail.com> wrote:
> *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.
>
Okay, well if you navigate to a view in JSF without a redirect, then JSF
will load that one mid-request and starts rendering it right away. The
Servlet API is not involved here and no security constraints are thus
applied.
This is actually a weakness of the navigate without redirect feature of
JSF, but there are unfortunately a few other things that are fundamentally
broken there as well.
It's a bit offtopic to discuss in depth here, but the short of it is that
JSF should execute almost the full lifecycle after
navigate-without-redirect, but instead goes straight to render response.
Kind regards,
Arjan Tijms
>
> On 7 May 2015 at 17:01, arjan tijms <arjan.tijms_at_gmail.com
> <javascript:_e(%7B%7D,'cvml','arjan.tijms_at_gmail.com');>> wrote:
>
>>
>>
>> On Thu, May 7, 2015 at 4:15 PM, Rudy De Busscher <rdebusscher_at_gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>