servlet
servlet copied to clipboard
jakartaee
Clarify behaviour with pre-emptive authentication
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?
- Issue Imported From: https://github.com/javaee/servlet-spec/issues/21
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @shingwaichan
@glassfishrobot Commented markt_asf said: Note: pre-emptive authentication can never work with DIGEST auth
@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 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 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 {
I couldn't really find a spec reference that says authentication for unprotected resources is optional.
@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 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 Commented This issue was imported from java.net JIRA SERVLET_SPEC-21