Hi Bobby,
Please remember that this is my first web application, and first time I
have to rely on J2EE security model.
I finally understood the J2EE model which basically means that the
developer for every application resource or group of them must define a
role and then later the administrator must create a group for each role,
assign users to groups and define the role group mapping, but I don't
like it.
I also don't like the ldap realm model which I think is wrong as I don't
like the JDBC realm model either,
which by the way I found both of them through forums goggling and not
through documentation.
I don't think defining security policy incide the code is the right
solution even if it is in the Java EE .
Maybe we should rewrite the standard. Or maybe I am just not used to
this model yet.
What I was expecting is the following.
The developer develops but the administrator will define the access
rights and all security policy that the company wants.
Most of the web applications today allows the users to register
themselves, and this is not supported very well by glassfish.
The administrator can define through the admin console, special users,
groups, default groups for those that register by themselves, place
users into groups, define roles and assign roles to groups, assign
access rights to roles etc.
When the administrator deploys an application all application resources,
that is, pages, beans, files etc should be visible in the admin console
so administrator can assign access rights to them. By default nothing
should be accessible.
Anyway after several weeks studying glassfish and the security model, I
think I would have to write my own custom login module and xhtml login
pages.
I tried a few examples I found about defining FORM login but it doesn't
seem to work with JSF and facelets.
brg
Nikolas
Στις 11/3/2011 7:37 μμ, ο/η Bobby Bissett έγραψε:
> 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
>
>
>