Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Shing Wai Chan
Reporter: markt_asf
Votes: 1
Watchers: 2

If you were logged in you would be able to see more operations.

Clarify behaviour with pre-emptive authentication

Created: 07/Oct/11 01:36 AM   Updated: 12/Feb/13 09:10 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Participants: arjan tijms, markt_asf, monzillo and Shing Wai Chan

 Description  « Hide

The HTTP spec allows pre-emptive authentication - i.e. sending credentials before the server asks for them. It is unclear from the Servlet spec how getRemoteUser() and friends should behave in this regard when the resource being requested does not require authentication. Should the credentials be processed or ignored?

markt_asf added a comment - 07/Oct/11 01:37 AM

Note: pre-emptive authentication can never work with DIGEST auth

monzillo added a comment - 10/Jan/13 06:46 PM

imv, we should apply an established authentication session when we access
an unprotected resource within the session; that is, assuming the authentication session
conforms to the session mechanism configured for the application. iirc, the spec is not
clear on that, and it could be worth adding that as a requirement.

Regarding the processing of authenticators included in requests to unconstrained resources, I think such authenticators should be ignored during constraint processing (for the required to be supported authentication mechanism processors). Conversely they should be processed if the target resource makes a call to HttpServletRequest.authenticate.

That said, I think we should allow custom authentication mechanisms to decide how they will treat authenticators sent to unprotected resources. In the servlet profile of jsr 196, the the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

arjan tijms added a comment - 09/Feb/13 08:04 PM

In the servlet profile of jsr 196, the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

Ron, is this tested in the TCK? At least JBoss EAP and AS don't do this at all, yet they are certified for Java EE 6.

arjan tijms added a comment - 11/Feb/13 11:01 PM

Doing some more digging in the JBoss code, I found an optional "valve" (it's not documented), via which JBoss EAP/AS do process unprotected resources as well. It has an interesting comment:

 * <p>
 * This class implements a JASPI authenticator for unprotected resources. In the JASPI Servlet profile, authentication
 * for unprotected resources is optional but it is still allowed. When performed, the JASPI authentication modules must
 * grant access to the unprotected resources irrespective of the caller, which may be anonymous (i.e, no security info
 * supplied).
 * </p>
 * @author <a href="">Stefan Guilhen</a>
public class WebJASPIOptionalAuthenticator extends ValveBase {


I couldn't really find a spec reference that says authentication for unprotected resources is optional.

monzillo added a comment - 11/Feb/13 11:24 PM

Arjan, You are correct that the Servlet profile of jsrs 196 requires that ServerAuthContex#validateRequest be called on every request that satisfies the connection requirements (i.e., any user-data-constraint). Other than the above exception this includes all request urls independent of whether the resource would have been authorized prior to the the call to ValidateRequest. That said, once the validateRequest is called, the authentication module is expected to behave differently if authentication is not mandatory for the request url. This is spelled out in section 3.8. The module specific details are described in
I will ask that the TCK add a test.

In the context of this issue in Servet, I would expect the same behavior to be required to handle "preemptive" authenticators, but as suggested by Mark, this could be limited to some specific auth mechanisms, in which case, it likely will be necessary to require the processing of an included authenticator.

markt_asf added a comment - 12/Feb/13 09:10 AM

One additional point of clarification. If the user pre-emtively sends a user name and password that are not valid (user doesn't exist, wrong password, etc.) to an unprotected resource how should the container react? Should it reject the request because the credentials are invalid or should it allow the request and just ignore the credentials. I lean towards the former as I am concerned that the latter approach may open the door to brute force password cracking attempts.