We Keep Coding

Vaadin and Spring Security: "/VAADIN/**" route

I have an application with Vaadin 8 and Spring Boot. Currently, I'm in progress of adding authentication to this app. So, I enabled Spring Security and started tinkering with it. Basically, I followed this tutorial: https://vaadin.com/tutorials/securing-your-app-with-spring-security/setting-up-spring-security
The approach, described there, works fine, however, I'm slightly disturbed by the fact that /VAADIN/** path needs to be publicly available (otherwise, Vaadin doesn't work). I mean, of course, I have protected particular pages by their paths (e.g. /admin) and unauthenticated users won't be able to open them, but isn't exposure of /VAADIN/** path dangerous? What if some hijacker tries to send some request to the Vaadin servlet outside of the UI (by simply curling it) with some specific headers/parameters? Is it possible that by formatting such request in some malicious way, the data will be actually returned to this hacker, bypassing Spring Security?

but isn't exposure of /VAADIN/** path dangerous
It is not dangerous per ce. The framework itself has just some generic parts there, like static resources for the client, like the widgetset and theme. Having said that, it is of course to be noted it application design. For example you should not put something that includes confidential info in your app as ThemeResource, but use ClassResource instead and things like that.

How to set session key in cookie for every request in jersey

I am using jersey for REST service. I am deploying the REST service using apache tomcat. How do i set the session key in every response.
I have tried the below piece of code
return Response.ok(response.toString(), MediaType.APPLICATION_JSON).cookie(new NewCookie("JSESSIONID", request.getSession().getId())).build();
where request is instance of HttpServletRequest. I want to is there any configuration in web.xml so that the JSESSIONID is set for every response

Generally speaking (this holds true for many frameworks!) anything you want to be used in multiple places is best done with a filter. I'm not going to show you exactly how you do it, as it is very simple and it is better for you to read the docs, but have a look here:
https://jersey.java.net/documentation/latest/filters-and-interceptors.html
You can apply these to both methods and classes, so you only need to place annotations in a couple of places.
A very useful thing for writing clean code!

Using JaaS with Jersey on Grizzly

I'm trying to find a simple, flexible way to add JaaS authentication to REST. I found a post that I think leads me in the right direction (See StevenC's answer). It sounds like the servlet container is responsible for security, not the Jersey code itself. I like this idea, but need a little guidance on implementation.
Grizzly is my servlet container and I want to configure it to use JaaS for authentication. For now, a simple username/password combination would be fine, and hard-coding the username/password pairs directly in code is fine. As long as it uses JaaS, we can refine those details later.
As far as what is sent over HTTP, I'm thinking that storing a cookie would be the easiest way to make this all work. Whatever it takes to keep authentication junk away from my Jersey code.
Here's the code to start Grizzly so far:
final String baseUri = "http://localhost:9998/";
final Map initParams = new HashMap();
initParams.put("com.sun.jersey.config.property.packages",
"my.jersey.Service");
System.out.println("Starting grizzly...");
SelectorThread threadSelector = GrizzlyWebContainerFactory.create(baseUri, initParams);
System.out.println(String.format(
"Jersey app started with WADL available at %sapplication.wadl\n"
+ "Try out %shelloworld\nHit enter to stop it...", baseUri, baseUri));
System.in.read();
threadSelector.stopEndpoint();
System.exit(0);
If this whole process works, what's the best way to check permissions for the user? I would probably want my REST code to actually validate permissions at certain points. Am I even on the right track? Is there an easier way? A link to a tutorial would be a great answer. Even an answer like "I did that and it worked" would give me a warm fuzzy that I'm heading in the right direction.
Thanks for any help.
EDIT: Some clarifications for StevenC's comment:
Do you still want to use servlet filters to protect your resources? I'll use whatever can separate out the authentication detail from the Jersey code. It doesn't have to be servlet filters.
What is mean by "configure it to use JaaS"? The original plan was to protect the current API using JaaS. The next phase would be to make the entire API available online. It seemed to make sense to have a Jersey wrapper around the API calls, but keep authentication handled by Grizzly. Grizzly would have to interact with JaaS at that point I believe.
Are you thinking there should be some config that simply causes grizzly to protect your resources? I was considering a two-step process of authenticating the user and based on roles, authorizing the user to access resources. The idea was to have Grizzly handle authentication (using JaaS) and Jersey handle authorization.
"I don't see the need for the usage of cookies with a RESTful resource." It would be wonderful to remove the use of cookies, but how can the be accomplished? The system needs to know if the user is authenticated. I'd rather not ask them to pass a username/password/etc for each call. Even passing a session token as a parameter with every call seems "ugly".
Also, please note that I'm fairly new to REST. I've been doing SOAP for a couple of years, so I may have a "SOAP bias" that may be blinding me from some obvious, simple solution that everyone uses. If there's an easier way, please feel free to share. I'm just trying to learn as much as possible.

I'm not entirely clear what is meant by "configure it to use JaaS for authentication". If there's a simple configuration to have grizzly enforce HTTP authentication protecting URLs, I don't know about it.
I'm assuming from the other question and answer you reference that you want to use a servlet filter. Normally that's configured in the web.xml file of a servlet project. Grizzly is of course often used to start up a server from code as opposed to application config. When I used grizzly in this way I noticed that GrizzlyWebContainerFactory didn't offer any versions of create() that allowed you to specify servlet filters. However I did notice ServletAdapter [1] in the same project that does give you that ability.
As for the filter itself, I unfortunately don't know of a pre-built servlet filter that simply plugs JaaS configured login modules into your application, so you'll likely have to write a bit of code there. It's not much though, just choose the HTTP based authentication method (e.g. HTTP BASIC, DIGEST, etc.), extract credentials from the request accordingly, and login using the JaaS framework. I don't see that a cookie would specifically be needed for RESTful resources. The RESTful architectural style frowns upon keeping sessions. There are plenty of tutorials about JaaS otherwise, so I won't elaborate on that here.
Once a JaaS subject is active (consumer successfully logged in) you can simply get the current subject and check the active principals and credentials using the Subject.getSubject method.
Anyway, this answer is specifically to give a bit more of the details around doing auth with servlet filters, as you requested in the other (linked) question. This isn't necessarily the only way to do auth in a jersey webapp, but it's a fairly straightforward way to do it. I like it because it keeps me from injecting repetitive auth code in each resource that needs it.
[1] https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/http/servlet/ServletAdapter.html

Not sure if you are asking how to secure each resource, but I found a presentation on javapassion that sounds like what you are looking for. He says to use #Context SecurityContext as a parameter.
#Path("basket")
// Sub-resource locator could return a different resource if a user
// is a preferred customer:
public ShoppingBasketResource get(#Context SecurityContext sc) {
if (sc.isUserInRole("PreferredCustomer") {
return new PreferredCustomerShoppingBaskestResource();
} else {
return new ShoppingBasketResource();
}
}

Are there any Java MVC frameworks that utilize request path patterns instead of defined servlet url patterns?

From what I know of MVC outside of the Java world (PHP and Ruby on Rails), all requests are first sent to the front controller (or dispatcher... or boostrap, etc.), and the front controller looks to the request path pattern in the URL in order to determine what class/method should handle the request. In Java MVC, it appears that servlets are mapped with the url pattern in the deployment descriptor (web.xml), but the file extension and url pattern doesn't appear to be very flexible. Are there any Java MVC frameworks that use a front controller to read the request path exclusively to determine what classes should execute? Would it be fairly easy to hack Spring MVC to do this? Any examples? Thanks!

An example of one tool that works as you desire is web4j.
By default, it maps incoming URLS to the Action class whose package-qualified name maps in a fairly natural way the the incoming URL.
Example from its docs:
Request URL: 'http://www.blah.com/fish/main/member/MemberEdit.list'
Extracted part of URL: '/main/member/MemberEdit'
Maps (by default) to the Action: 'hirondelle.fish.main.member.MemberAction.java'
This is an example of how that particular tool performs the task. Since this is such a basic feature of web apps, I would imagine that nearly all such tools have similar mechanisms.
I am not a big user of Spring, but I can see from its docs that it has a number of ways of mapping requests to Actions :
SimpleUrlHandlerMapping
ControllerClassNameHandlerMapping

Java servlet mappings can also be by file extension.
Much like many non-Java frameworks, you could map all requests to a single servlet that then processes them but that tends to be discouraged in Java. It's certainly possible though.
If you want more REST-style URLs where you declare the mapping of path elements, you might want to look at the Spring MVC setup in Spring 3.0.

I agree the URL mapping is not very flexible but you can handle mapping with URLRewriteFilter
http://tuckey.org/urlrewrite/
For this purpose, the filter works almost like a controller.

Check out stripes:
http://www.stripesframework.org/display/stripes/Quick+Start+Guide
I've been looking at it as a possible upgrade from struts. There is an example on that page that is very similar to the web4j example given by John O.

Spring MVC REST : static files unaccessible because of url-pattern

My Spring Dispatcher servlet url-pattern is /* (as spring MVC REST suggests)
Now all the request are resolved by this Servlet. even CSS/JS/Images also get resolved and handled by servlet..
So, Spring MVC tries to find controller.. :(
How to bypass this? Is there any standard way out of this problem??
& Don't want to change url-pattern to /rest/* (so, other static resources get accessed by /css/ or /js etc.)

You can map your controllers to a smaller set of URLS (i.e. /app/*), and then rewrite the URLs that your users actually see so that they don't even know about. Have a look at the mvc-basic webapp sample, particularly web.xml and urlrewrite.xml to see how this is done.

Map the Spring dispatcher to some subsection of the URL space, and use Tuckey to rewrite URLs the user deals with.
http://www.example.org/app/controller/action -> http://www.example.org/controller/action

Just a heads-up update on this: the default rewrite configuration as defined in the Spring sample did not work out of the box for me. The rewrite rules for stylesheets, scripts, etc. were still processed to the /app/* rule, and subsequently handled by the DispatchServlet, which is not desirable.
I had to add the last="true" attribute to the styles/scripts/images rules to indicate that other rules should not apply, and I had to use the FreeMarker Spring URL macro in any CSS/JS include paths.
Just in case someone encounters the same problem.