Clarify behaviour with pre-emptive authentication about servlet

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/21
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @shingwaichan

[glassfishrobot]

@glassfishrobot Commented
Reported by markt_asf

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
Note: pre-emptive authentication can never work with DIGEST auth

[glassfishrobot]

@glassfishrobot Commented
monzillo said:
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.

[glassfishrobot]

@glassfishrobot Commented
arjan_t said:

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.

[glassfishrobot]

@glassfishrobot Commented
arjan_t said:
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="mailto:[email protected]">Stefan Guilhen</a>
 */
@SuppressWarnings("unused")
public class WebJASPIOptionalAuthenticator extends ValveBase {

(see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.1.2.Final/org/jboss/as/web/security/jaspi/WebJASPIOptionalAuthenticator.java#WebJASPIOptionalAuthenticator)

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

[glassfishrobot]

@glassfishrobot Commented
monzillo said:
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 3.8.3.1.
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.

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
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.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-21