On Mar 11, 2011, at 6:17 AM, java4dev wrote:
> Of course it is not acceptable to define authorization rules, roles etc inside the code with annotations and
> even though defining authorization rules in web.xml file is certainly better than inside the source it is still
> far from a proper solution
I'm not sure what you mean by this. When you write some code, I don't see the problem with annotations to restrict who can access it. For instance, imagine these two methods in some hypothetical application: getMyData() getAllData(). The first could be restricted to a "users" role, and the other to an "admin" role. Since the purpose of those methods can't change dynamically, I don't know why the roles would. Note that roles are *not* users.
Now in order to use the above methods, you need some way to get users into roles. This is where groups are very useful. One app server installation may use groups called "users" and "admin." Another could be set up already with "customers" and "webmasters" or any random name. The point of group to role mapping in the deployment descriptor is that the *same* application can be deployed in either case just by mapping the group names to the role names.
Beyond that, you can dynamically switch what group a user is in by changing the data in the table (or ldap server). This will change what role the user is in within the application. Please note that this is not just the way GlassFish works -- this is how it works in Java EE (off course there are other solutions built on top of this infrastructure that Kumar included in his last email).
This may help with the group/role distinction:
http://blogs.sun.com/bobby/entry/simplified_security_role_mapping
Cheers,
Bobby