Precedence of security-constraint over filters in Servlets

Question

While studying about security-constraints and filters in servlets, I made the following declarations in the web.xml file, which didn't work as I expected:

<security-constraint>
    <web-resource-collection>
      <web-resource-name>BeerSelector</web-resource-name>
        <url-pattern>/SelectBeer.do</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
      </web-resource-collection>
     <auth-constraint>
        <role-name>Admin</role-name>
     </auth-constraint>
 </security-constraint>


  <filter>
   <filter-name>LoginFilter</filter-name>
   <filter-class>model.MyFilter</filter-class>
  </filter>


  <filter-mapping>
  <filter-name>LoginFilter</filter-name>
  <url-pattern>/SelectBeer.do</url-pattern>
  </filter-mapping>

According to what I read: filters should be encountered before the request reaches a certain url, so, how come the security-constraint is invoked first ?

I know that it makes sense from a security wise (to reach the filter you mush be authenticated), but I'd like to know the sequence triggered by the request.

Does the container searches first for the secured resources thus it triggers the security-constraint?

But this will contradict with the following paragraph quoted from Head First Servlets and Jsp "

Remember that in the DD, the is about what happens after the request. In other words, the client has already made the request when the Container starts looking at the elements to decide how to respond. The request data has already been sent over the wire

or maybe the request just triggers both: filter and security-constraint, but the security-constraint is favored over the filter ?

Answer 1

The container processes the security constraints first.

In a nutshell the Servlet container first examines the incoming URL and checks if it matched the so-called excluded or unchecked constraints. Excluded means the URL can not be accessed by anyone, while unchecked means the opposite and allows everyone to access the URL.

At this stage the container can call your own code if you installed a so-called JACC provider.

After this the container may try to authenticate the current user, where it can call your own code again. If you registered a SAM (ServerAuthModule) this will always be called at this point, if you didn't register a SAM or when you are working with a non-full Java EE implementation (e.g. a Java EE web profile server like TomEE or a bare Servlet container like Tomcat) it depends on the server if some kind of server specific login module is always called (rare) or only called when access is not granted to the unauthenticated user (typical).

The SAM is a filter-like thing as it can redirect, forward and wrap the request and response, but it's not an HTTP Servlet Filter.

After authentication succeeds your JACC Policy will be called again, or when you haven't installed one the container will use a proprietary mechanism to see if you now have access when authenticated.

If it's indeed determined that you have access, the so-called "resource" will be invoked, which means the container will call the first Filter in the filtering chain, which will eventually call through to the target Servlet to which the requested URL was mapped.

You can read more about the SAM here: http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

And more about JACC providers here: http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html

Answer 2

Filter execution comes into the "serving" side of the request. Security constraints operate prior to that. They help the server decide whether the url will be served. You can think of filters role as something that executes "just before/after servlet execution".