I come from a C# background and so I am new to Vaadin (and Java EE) so struggling a bit to get my head around a few things. So apologies upfront if this turns out to be a stupid question!
I have been asked to look at using Vaadin for a new application where this would be deployed on Glassfish. I have had a play around with several tutorials and I like what I have found. I am now at the point where I want to look at building a simply logon mechanism but I am getting a bit lost in regard to the best way to do this.
As far as I can tell I can create user and roles in Glassfish (http://download.oracle.com/javaee/6/tutorial/doc/bnbxj.html) and I know that this is the way the company would prefer to manage users and groups i.e. as opposed to me creating tables in a database and building screens and logic to support it . It seems doing it here is very powerful and provides loads of other options.
In order to support app server (glass fish) based security, you have to define the proper realm for your web application in a web.xml or via annotations.
Please see the following url for more information -
http://download.oracle.com/javaee/6/tutorial/doc/bnbxj.html
The trick is that Vaadin has a getUser() method to return a “user” which can be anything you want. In JavaEE security, a “principal” is the magic name for who is calling you. If you look at the article, you will see that you can override the ApplicationServlet so that the principal from GlassFish (or any J2EE server) gets injected as the “user” in your Application object, and then you can do a getUser() to retrieve the principal and all the associated permissions…
You are actually taking the black belt approach – connecting Vaadin to the container. Until J2EE 6 this was very painful to do, and most people did not bother, they would build their own security mechanism independent of the container’s. There are various extensions that do this (see for example the AppFoundation add-on),
In actual practice, you will likely need a hybrid approach – if for example, managers can see payroll sheets, but not the one for their boss, this is a restriction on instances, not based on roles, and you will likely have additional application-level tables. Connecting these tables to the J2EE realm will be the real challenge.
The included screen cast was lost when the blog moved from sun.com to oracle.com, but all the code is there. In this example, I’m using the default realm in GlassFish that is a simple file-based realm. It all works fine, but users need to be manually added to that realm through the GF admin console. But once you have it working generally, you can move your application to use a different realm with just a change in one deployment descriptor.
One other note: if you use the same names for groups and roles (IOW, users are in a group called “USER” and your app uses a role “USER”), then you don’t need to include a group-to-role mapping file. Instead, you can turn on “default principal to role mapping” in the server:
