Hi,
>
> I don't know how the
> default-principal-to-role-mapping gets the list of
> groups it creates roles for. If it only happens at
> initial deployment before ServletContextListeners are
> triggered, then this would be an issue. I can also
> envision install issues should one of our modules
> fail to deploy properly. I get the general feeling
> that this one-to-one mapping of a group to a role is
> a workaround, not desired behavior, and that this
> particular server property is a hack, designed to
> facilitate somewhat simpler migrations from other
> application servers. I think there are a few issues
> that would prevent me from using it this way.
>
The Java EE model is that an Application developer declares Roles. This is done either using Annotations or in web.xml
And at deployment time the roles be mapped to groups/principals. This is done in sun-web.xml where you map groups to roles. Principal to role mapping as you already noted does not scale.
So the default-principal-to-role-mapping feature saves you from having to write a sun-web.xml if the groups in the backend have the same names as the roles defined.
But if the set of groups is dynamic (i.e. new groups are created over the lifetime of the app) then your app is not compatible with the default JACC provider in GF V2. It would need redeployment since GF JACC Provider uses a static policy file. What can ofcourse change is what users exist, and what groups (of the static set) they are members of.
So can you clarify what you mean by : "our customers have runtime control over users, groups and the roles assigned to them." ?. Which things can change dynamically over the lifetime of the app.
1. Number of Users would change and their group memberships can change
2. Does the set of groups defined change or is it a static set. Will there be a increase or decrease in the number of groups ?
3. Does the set of roles keep changing or is it a static set ?. And i guess you are also saying that the set of groups with are in a given role also changes is that correct ?.
>
> 2] I really want to override the RoleMapper somehow
> through configuration. I'm trying to determine if
> this is possible without having to modify the source
> and recompile Glassfish itself. I doubt I could get
> the green light from my supervisors to deploy to
> production like this. It seems to me that there
> should be three parts to a custom realm
> implementation: Realm, LoginModule and RoleMapper. I
> already need to create my own AppsrvRealm to tweak a
> couple of things (and I was disappointed to discover
> that
> com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm
> is marked "public final").
So it is possible to override the RoleMapper although not with the default JACC provider. There is a new In-Memory JACC Provider introduced in V3 Prelude. It is implemented as a pluggable module and it provides a way to plugin your RoleMapper. You can plugin this provider into your GF V2 system.
And if you wish you can also write your own JACC provider to handle your usecase. The In Memory JACC Provider can help you as a starting point for doing that.
I discussed at length with our architect and he actually wanted me to do some experiment before replying to you, but since you raised the issue of overriding RoleMapper through configuration, i thought i might as well reply.
If you want more details about the In Memory JACC Provider see this blog from Ron :
http://blogs.sun.com/monzillo/
> [3] I could just migrate away from container managed
> security using some third party framework, but this
> is definitely not minimal impact.
>
>
> I just don't understand this implementation. The
> appserv-rt.jar contains
> org.apache.catalina.realm.JDBCRealm but I'm not able
> to use it, because I need an AppsrvRealm derived
> class. Catalina realms understand roles, AppsrvReamls
> understand groups ... at first this seemed like a
> real win for the AppsrvRealm, but not having a way to
> map roles to the users/groups in the database is a
> big downfall. It would be really cool to have this
> ability.
>
The Realm is just a little more than a JAAS LoginModule in the sense that it understands groups, and is a backend entity which ideally should not have anything to do with Roles which are application specific.
But your point about having configurability for the RoleMapper is taken. We would like to help you to make sure your usecase can be handled well with GF. Let us know what we can do to help the situation.
Thanks.
[Message sent by forum member 'kumarjayanti' (kumarjayanti)]
http://forums.java.net/jive/thread.jspa?messageID=321388