On 11/27/14 7:50 AM, arjan tijms wrote:
> Hi,
>
> On Thu, Nov 27, 2014 at 11:53 AM, Mark Thomas<markt_at_apache.org> wrote:
>> Do we want to add some clarification in the spec on this? Currently the
>> expected behaviour when a user agent pre-emptively sends credentials for
>> an unprotected resource is undefined.
> In JASPIC at least this actually is defined. It basically boils down
> to the spec saying:
>
> * An auth module should always be called for each request, whether the
> resource is protected or not, and whether the user previously
> authenticated within the http session or not.
> * An auth module is allowed to opt-out of authentication, e.g. "doing nothing"
Arjan,
Whether an Auth Module is "allowed" as you say to "opt-out" of
authentication is
dependent on the RequestPolicy argument passed to the auth module from
the container.
When the request policy contains a "mandatory" authentication policy,
the Auth Module
has no such discretion. It can choose to fail the authentication, but it
cannot return a success
outcome unless it has set an authentication result.
In validateRequest (with mandatory requestPolicy)
there are basically 3 outcomes: success, continue authentication, and
failure;
these align with the 3 outcomes of authenticate: true, false, exception
Also the "Sub-profile for authenticate, login, and logout of
HttpServletRequest"
of the Servlet Profile of JASPIC requires that when authenticate is
bound to the JASPIC SPI,
that the RequestPolicy be set to mandatory. see section, " 3.9.3
Processing for HttpServletRequest.authenticate" for details.
Ron
> With regard to pre-emption, there are two cases:
>
> * A user agent pre-emptively sends credentials and the auth module
> that's invoked prior to the resource invocation can opt to process
> these
> * User code in a Servlet pre-emptively sets credentials (e.g. as
> request attributes) and calls request.authenticate, upon which the
> (same) auth module can opt to process these again
>
>> Should we define the expected
>> behaviour, define the options but leave the implementation to the
>> implementor, define the options add something to web.xml to standardise
>> configuration, something else...
> I would say define the expected behaviour, and linking to or aligning
> with JASPIC wherever appropriate.
>
>> I don't think we can re-define the meanings of the return values. That
>> might break stuff. (Generally, I'm happy to deprecate and then remove
>> features even through that might break very old stuff but experience
>> tells me that the JavaEE folks view that as a no go.)
> That's indeed true. The slightest theoretical breakage of old stuff is
> often viewed as a no go.
>
> I should do some testing myself, but I wonder, does anyone already
> know if there are or were any servers out there besides Undertow
> 1.1.0+ that actually throw an exception when the result of
> request.authenticate() is that "nothing happened"?
>
>>> 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 ... ?
>> It depends on what we want to do about pre-emptive authentication for
>> unprotected resources. Depending on how we opt to treat that, we might
>> not need a new method.
> Okay, so let's see what happens in that discussion first then.
>
> Kind regards,
> Arjan Tijms