users@glassfish.java.net

Re: Re: Nested groups

From: Per Steffensen <steff_at_designware.dk>
Date: Fri, 21 Aug 2009 18:49:13 +0200

Hi

We are using Glassfish v2.1. Is it corrent that there are no
nested-group support in that version of Glassfish?

I shortly read through your descriptions below. It sounds like you will
support nested groups during deployment descriptors (or maybe
annotations). I dont believe that it is the right way, because by doing
it that way, that group structure will be static pr. application
deployment. It should be the realm (provides dynamic changes to group
structure, without deploying new application) that supports nested
grouping. In the realm right now, you can put users in groups. The realm
should also support to put groups in other groups. That way you have a
much stronger dynamic mechanism to control user access rights on the fly
(using a admin tool)

Regards, Per Steffensen


Kumar Jayanti skrev:
> Per Steffensen wrote:
>> Hi
>>
>> Is there any way realms or security in general in Glassfish supports
>> nested groups. Security is controlled by putting some users in
>> different groups, mapping groups to roles and assign roles the access
>> to perform some service operations. The roles and roles-to-groups
>> mapping is done by the application. Groups and users in groups are
>> defined by a pluggable realm. But how can I (out of the box) make
>> realms support nested groups. By nested groups I mean a feature,
>> where not only users can be put in groups, but where groups can also
>> be put in other groups. The funtionality I want is that not only
>> users in a specific group A will be granted access to the roles
>> associated with group A. Users in groups B and C which is added
>> inside group A will also be grant access to the roles associated with
>> group A. With that functionality you can build hierarcies of groups,
>> making it easies to administrate groups.
>>
>> Does realms in Glassfish support any kind of nested groups?
> recently in GlassFishV3 we tried to add a Group Mapping facility for
> realms. The semantics of this group mapping is still being discussed
> but with the latest V3 bits you can exercise this feature for
> LDAPRealm. We did not implement this for other realms but the base
> Realm class has the callable protected method that can be used by any
> concrete realm impl.
>
> protected ArrayList<String> getMappedGroupNames(String group);
>
> The syntax for configuring the group mapping is as follows :
> ---------------------------------------------------------------
> Here is how to configure it as an example :
> <auth-realm
> classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm"
> name="admin-realm">
> <property name="jaas-context" value="ldapRealm"/>
> <property name="group-mapping" value="gdomain1->asadmin"/>
> </auth-realm>
>
>
> The general syntax allowed for the property value above is :
>
> MappingValue ::= Mapping (; Mapping)*
> Mapping ::= GRPLIST -> MAPPEDGRP
> GRPLIST ::= GRPNAME (, GRPNAME)*
> MAPPEDGRP ::= GRPNAME
> GRPNAME ::= {any valid group name, it should not
> contain the sequence ->}
>
> So i could write something like :
> <property name="group-mapping" value="a, b, c->d ; d,e,f->g " />
> ----------------------------------------------
>
> I am discussing the semantics of this with Ron currently. What has
> been implemented would do the following currently :
> if realm authentication returned group {a} in the sample above then
> the result of applying groupmapping would be the list of groups {a, d, g}.
>
> The point of discussion with Ron currently is the following :
> ---------------------------------------
> 1. disable any *implicit* (same named mappings), requiring that they
> be included in the specification if they are to be performed. If you
> take this apparoach a mapping of X->Y would disable the implict
> mapping of Y->Y. I think sharing a common repository in different
> contexts, will depend on an ability to be explicit about which group
> attributes will map to which group principals.
>
> I am yet to implement the above behviour.
> ---------------------------------------
>>
>> Regards, Per Steffensen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>