Hi,
On Tue, Dec 2, 2014 at 5:38 PM, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
> When authenticate is called, the container authentication mechanism has no
> discretion as to whether
> or not authentication is to occur. IOW, the method was created to allow the
> application to
> be authoritative for when authentication must occur (as distinct from the
> situation where the container's constraint processing system would otherwise
> be authoritative - based on path base security constraints - for
> establishing when authentication is to occur).
First of all, thanks a lot for the (as always ;)) very clear
clarification. I'm not exactly sure where I missed the above, but
apparently I did. Perhaps something like the text above could be added
as clarification to the Javadoc of that method?
> IOW calling authenticate is equivalent to calling a JSR 196 auth module with
> a *mandatory* authentication policy.
>
> The authentication method was NOT defined to support an "authenticate if you
> (the container authentication mechanism) thinks it is appropriate to do so"
> use case.
Okay, so that's clear. Possibly we then may need a new API indeed. The
use case I'm after is simply the programmatic variant of giving an
auth module the opportunity to authenticate or not, in analogy to the
opportunity the auth module is given prior to invoking a resource.
The reason for this is setting up a proper context in which the auth
module can function, e.g. setting up CDI, the Java EE component
namespaces, and what have you.
The flow would then be:
1. Start of request
2. Auth module called prior to resource invocation - checks if context
is available, if not "does nothing"
3. Resource is invoked - Something, e.g. a ServletRequestListener sets
up context.
4. Filter is invoked, calls req_at_authenticate
5. Auth module called during resource invocation - checks if context
is available again, if so checks if there's any pre-emptive auth token
in the request, if not again "does nothing"
Of course there are other ways to solve this, for instance via a
ServletRequestListener provided this triggered before an auth module
is called (in some Servers this indeed happens, so perhaps another
avenue is to clarify/amend the spec for this)
Kind regards,
Arjan Tijms
>
> If you need to support that use case, you will need to define a new API. The
> existing API was defined to allow frameworks such as JAX-WS and JAX-RS to
> trigger authentication based on non-path based mechanisms, such as
> @RolesAllowed.
>>
>> Most servlet containers I tested just return false when "nothing" has
>> happened, but to the letter of the spec this seems to be not entirely
>> correct.
>
> that sounds like a bug
>>
>> At least one servlet container has tried to implement the
>> spec more correctly, and has interpreted that the requirement is here
>> to throw a ServletException following its Javadoc:
>>
>> "ServletException - if the authentication failed and the caller is
>> responsible for handling the error (i.e., the underlying login
>> mechanism did NOT establish the message and HTTP status code to be
>> returned to the user)"
>
> the auth mechanism should not be refusing to perform the authentication, but
> it should
> throw this exception under the conditions as described.
>>
>> But IMHO, this is not entirely in the spirit of the spec either.
>> Authentication did not "fail" and there is no "error". The auth module
>> completely within its rights chose to do nothing.
>
> I believe you are defining a new use case/policy model for container
> authentication.
>
> The authenticate method was defined as an analogue for what happens
> when there is a (path-based) authentication constraint on a resource; In
> that case, the
> constraint enforcement system invokes the container authentication mechanism
> when an
> authentication constraint must be enforced. Likewise, the caller of
> authenticate has
> determines (by its own means) that an authentication contraint must be
> enforced, and it calls authenticate to direct the container authentication
> mech. to do so.
>
> Ron
>
>>
>> I wonder if anyone can suggest a way to improve this?
>>
>> Redefine the false outcome to just say authentication did not happen? I.e.
>>
>> return true -> authentication has happened
>> return false -> authentication did not happen
>>
>> Or introduce a new authenticate method returning say an enum:
>>
>> AUTHENTICATED -> authentication has happened
>> IN_PROGRESS -> authentication is incomplete
>> DID_NOTHING -> auth module decided to do nothing
>>
>> Or ... ?
>>
>> Kind regards,
>> Arjan Tijms
>
>