users@servlet-spec.java.net

[servlet-spec users] Re: Clarify / improve HttpServletRequest#authenticate?

From: Mark Thomas <markt_at_apache.org>
Date: Thu, 27 Nov 2014 10:53:10 +0000

On 26/11/2014 14:24, arjan tijms wrote:
> Hi,
>
> Currently the Javadoc for HttpServletRequest#authenticate states the
> following for the return value:
>
> "true when non-null values were or have been established as the values
> returned by getUserPrincipal, getRemoteUser, and getAuthType. Return
> false if authentication is incomplete and the underlying login
> mechanism has committed, in the response, the message (e.g.,
> challenge) and HTTP status code to be returned to the user."
>
> See https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#authenticate(javax.servlet.http.HttpServletResponse)
>
> Simplified that's:
>
> true -> authentication has happened
> false -> authentication is in progress and something has been
> committed to the response
>
> This however leaves out one important case, and that's when the using
> code wants to pre-emptively trigger authentication, but the auth
> module decides to "do nothing" (which, depending on its policy, can be
> a valid action).

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. 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...

> 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. 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)"
>
> 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 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

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.)

> 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.

Cheers,

Mark