We Keep Coding

Tomcat web.xml: restrict access to specific methods of a servlet

I'm running a web application under Tomcat server. Different servlets are configured using Tomcat's web.xml.
I'm looking for a convenient way to restrict access to specific METHODS of specific URLS so that only these METHODS can be accessed using an Authorization header while others can be accessed without any restriction.
For instance, for url http://localhost:8080/my/servlet1 - GET and OPTIONS can be accessed by any user, while POST and PUT must be authorized with a username and a password, but for url http://localhost:8080/my/servlet2- all methods are open.
How can I implement that?
Thanks

The most low level API that allows you to do all sorts of filtering based on the context of the HTTP request in the javax/servlet/Filter
You implement a filter class that can restrict on the basis of HTTP method and any other criteria you choose. You register the filter on your web.xml and you add rules for which paths it is filtering.
Here is an walk through on applying such a filter.
If you happen to be using more than just a naked Tomcat for your application and you are using Spring Boot on top of it you could use their flavor of filters. This is an example for that case.

Why and when use dynamic servlet registration?

I'm investigating a Spring Boot project generated by JHipster and found out that its request mappings aren't done via web.xml nor via Spring's #RequestMapping but like so:
ServletRegistration.Dynamic someServlet =
servletContext.addServlet("someServlet", new SomeServlet());
someServlet.addMapping("/someUrl");
someServlet.setAsyncSupported(true);
My questions are:
Are there any reasonable advantages of dynamic registration instead of classic mapping?
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?

Is there any reasonable advantages of dynamic registration instead of classic mapping?
Dynamic servlet registration Servlet 3+ way of registering servlets. In Servlets 3 you can avoid creating web.xml and configure application in pure Java. It gives you some advantages like compile time check if everything is fine there and what's more important since you do it in Java code, you can do some additional checks or conditions - for example register particular servlet only if environment property is set or class is available on the classpath.
It's not a replacement for #RequestMapping. In case of Spring Boot you will use it most probably when you want to register some 3rd party servlet - like Dropwizard Metrics servlet in case of JHipster.
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
There are at least 2 ways of registering additional servlets in Spring Boot. See answers here: How can I register a secondary servlet with Spring Boot?.
Your own controllers you map as usual with #RequestMapping.
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?
Nope. For setting this header you use usually CORSFilter (read more: Enabling Cross Origin Requests for a RESTful Web Service). asyncSupported flag is used to make servlet able to process request asynchronously.

Spring security #PreAuthorize("hasAnyRole('....')")

I am using spring security #PreAuthorise to check who and who cannot access methods in my service layer. It works really well. Usually my service methods are annotated with
#PreAuthorize("hasAnyRole('MY_USER_ROLE')")
My problem is that I have a war file made up of several jar files. Each of these jar files is responsible for a segment of business logic. I now want one of the services in one jar file to access another service in another jar file. This gets rejected because of the permissions. If I comment out the permission then everything works.
Is there anyway I can authenticate via spring before calling this service? (Perhaps with a dummy user?) Or perhaps turn off the security for jars within the same application? Or is my design wrong?
Anyone else has this sort of problem? What design should I use instead?

You need to give the thread that invokes the service (in the other jar) the permissions that are required by #PreAuthorize (for the invoked service).
If the thread is triggered in an web application by an user request, then this are normally the users permissions.
But if the thread is triggered by some timer service then you need to give them the right authentication
Authentication authentication = new UsernamePasswordAuthenticationToken("dummy", "password");
SecurityContext securityContext = SecurityContextHolder.getContext();
securityContext.setAuthentication(authentication);

I believe this is a good example where you should use Spring security #Secured annotation
What is #Secured annotation?
From version 2.0 onwards Spring Security has improved support substantially for adding security to your service layer methods. It
provides support for JSR-250 annotation security as well as the
framework's original #Secured annotation.
Source: Spring Security 3.1 Reference 2.4 Method Security
#Secured annotation allows you to put restrictions in your methods. For example, you can authorize a get() method to be accessible by all
registered users. But for the edit() method, you can mark it be
accessible by admins only.
Check out some tutorials at:
http://burtbeckwith.com/blog/?p=1398
http://krams915.blogspot.in/2010/12/spring-security-3-mvc-using-secured.html

Spring security: using relative path

I have an application with name test.war.
Because of Apache installed on my server I have to use another port number for Tomcat applications so after deployment this application available at domain.com:8080/test/.
I decided to create a subdomain in order to remove that ugly 8080 from url, so I setted up the server like described here. So now test.domain.com reffers to domain.com:8080/test/.
Everything seems fine except of one problem - because my application is not ROOT.war and I am using spring:url function every url in the application is translated to /test/bla-bla. So I removed that function. But still have a problem with spring security because it still translates an urls relative to app name i.e. /test/bla-bla.
How can I solve that problem?
Thank you
UPD: I don't want to deploy it as a ROOT application because I have two or three such applications and I wanted to create a subdomain for each one of them

Spring Security doesn't "translate" URLs. In fact this isn't specific to Spring Security. You'll run into similar issues with any application which does redirects. If you want to hide the context paths of applications which are behind a proxy, then you need to rewrite the URLs at the proxy.
I'd recommend you read the Tomcat Generic Proxy Howto and the section on URL rewriting in particular, as it specifically addresses this issue.

Can Apache restrict access based on a Tomcat webapp's Spring SecurityContext?

We have a tomcat webapp which provides webservices which are protected using Spring Security. The client makes a call to a specific authenticationService method which we wrote to authenticate them and create an authToken which is then used to register them with Spring Security as so:
SecurityContextHolder.getContext().setAuthentication( authToken )
That's all fine and good. However, we also have the requirement that authenticated users be able to access static content which is served by Apache (httpd) on the same server. Is there a way to enforce the requirement that the user has been authenticated (by Java/Spring) before they can download the static content? It seems like Apache and Tomcat would have to somehow share the SecurityContext.
OR - alternatively it seems like Tomcat could serve the static content itself since it already has access to the SecurityContext. If that is the best solution, could anyone provide a pointer to how we would get tomcat to do that (serve static content after checking that the user has been authenticated).
Thanks.

Yes, Tomcat is going to have to serve the static content.
mvc:resources can be helpful here. After that is set up protect those mappings using the standard intercept-url configuration.