[security-dev] Group clarification

[Marek Posolda]

Hi Anil,

We discussed yesterday a bit with Pedro. PL IDM 1.x supports that some 
part of the group tree is mapped to some Ldap DN and different part is 
mapped to other DN.

For example:
All Subgroups of group "/org" are mapped to 
"ou=Qa,o=something,dc=jboss,dc=org"
And all subgroups of group "/differentOrg" are mapped to 
"ou=DifferentOrg,o=something,dc=jboss,dc=org"

This mapping is specified in idm 1.x configuration file. So 
configuration could look like:
"/org/*" -> "ou=org,o=something,dc=jboss,dc=org"
"/differentOrg/*" -> "ou=differentOrg,o=something,dc=jboss,dc=org"

Wit this configuration, the top group itself like "/org" is saved in 
default identity store (usually DB) but subgroups are stored in LDAP. So 
for example group "/org/users" is saved in LDAP as 
"cn=users,ou=org,o=something,dc=jboss,dc=org"

So in 1.x there is restriction that groupName needs to be unique for 
each part of Ldap tree. So you can have group "/org/a" and 
"/differentOrg/a". But you can't have "/org/a" and "/org/something/a" 
(Two groups with name "a" can't be under "/org" subtree)

Regards,
Marek

On 08/02/13 00:36, Anil Saldhana wrote:
> How does the LDAP DIT look like (for same groups different parents) in
> PL IDM 1.x?
>
> On 02/07/2013 02:11 PM, Bolesław Dawidowicz wrote:
>> +1
>>
>> On 02/07/2013 08:34 PM, Shane Bryzak wrote:
>>> This looks good.
>>>
>>> On 07/02/13 13:42, Pedro Igor Silva wrote:
>>>> Just to consolidate what was discussed:
>>>>
>>>>        - Change the getGroup(String) method to expected a path. And not the group name anymore.
>>>>
>>>>              identityManager.getGroup("/a/b/c/d")
>>>>
>>>>        - The getGroup(String, Group) should expect the name and a parent. Or null parent if you want the root group.
>>>>
>>>>        - Add to the Group interface a getPath method. From where you can get the group names hierarchy.
>>>>
>>>>              "/a/b/c/d".equals(identityManager.getGroup("/a/b/c/d").getPath())
>>>>
>>>> Is that it ?
>>>>
>>>> Regards.
>>>> Pedro Igor
>>>>
>>>> ----- Original Message -----
>>>> From: "Shane Bryzak" <sbryzak at redhat.com>
>>>> To: security-dev at lists.jboss.org
>>>> Sent: Thursday, February 7, 2013 2:29:14 PM
>>>> Subject: Re: [security-dev] Group clarification
>>>>
>>>> On 07/02/13 11:21, Bolesław Dawidowicz wrote:
>>>>> We had some chat on IRC and it turned out there is also currently no
>>>>> method to obtain the "path ID" of the group. I wondered why it was dropped.
>>>> It was dropped because we refactored the identity model so that all
>>>> identity classes had a unique id (UID) value. We should probably add a
>>>> different method for Group that returns the "fully qualified" name, but
>>>> it can't be called getId() now.
>>>>> For me if we allow only one parent group it makes the model natural tree
>>>>> hierarchy anyway. Then if you allow /a/b/c/a/b (5 different groups) it
>>>>> is handy to be able to obtain such path in a single call. However I
>>>>> think it should be really stored on a group level. Calculating it on
>>>>> demand can be performance concern. Deep trees are not that often design.
>>>>> In most LDAP schemas I witnessed deepest was around 3-4 levels. However
>>>>> if it happens then such calculation will result in N calls to DB/LDAP.
>>>>>
>>>>> Something like this would be handy IMO:
>>>>>
>>>>> identityManager.getGroupById("/a/b/c/a/b").getId().equals("/a/b/c/a/b");
>>>>>
>>>>> it can be path or key instead of id if it fits current design better.
>>>>>
>>>>> I also wonder about groups without hierarchy (no parent) scenario. If
>>>>> there should be null parent or some special root entity.
>>>>>
>>>>> On 02/07/2013 05:03 PM, Shane Bryzak wrote:
>>>>>> We should already support it.  If it doesn't work, please raise an issue
>>>>>> in jira (PLINK) and assign to me.
>>>>>>
>>>>>> On 07/02/13 07:02, Marek Posolda wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> One of the current requirements in GateIn is possibility to have groups
>>>>>>> with same name and with different parents. For example: I can have
>>>>>>> groups "/qa/management" and "/dev/management"
>>>>>>>
>>>>>>> In other words, I have two groups called "management" but both are in
>>>>>>> different parts of group tree, because first one has parent group "qa"
>>>>>>> and second has parent group "dev". Currently Picketlink IDM 3 doesn't
>>>>>>> support it (it always throws exception when it recognize that group with
>>>>>>> same name already exists). Also I am seeing that concept of GroupID
>>>>>>> (path to group from root group - something like "/qa/management") and
>>>>>>> group key has been removed as well even if it was supported in IDM 3.x
>>>>>>> couple of weeks before.
>>>>>>>
>>>>>>> Also for read usecase, there are two methods in IdentityManager to find
>>>>>>> groups:
>>>>>>>
>>>>>>>             Group getGroup(String groupId);
>>>>>>>
>>>>>>>             Group getGroup(String groupName, Group parent);
>>>>>>>
>>>>>>> I think that first one has been designed to find group with argument as
>>>>>>> groupId, so usage could looks like:
>>>>>>>
>>>>>>> Group qaManagersGroup = identityManager.getGroup("/qa/management");
>>>>>>>
>>>>>>> Second one has been designed with usage of plain group names like:
>>>>>>>
>>>>>>> Group qaGroup = identityManager.getGroup("qa", null);
>>>>>>> Group qaManagersGroup = identityManager.getGroup("management", qaGroup);
>>>>>>>
>>>>>>>
>>>>>>> Problem is that currently we are always using first one with groupName
>>>>>>> as an argument (not groupId), so it obviously can't work correctly if we
>>>>>>> have two groups with same name "management" because it's unclear which
>>>>>>> one should be result of finding...:-\
>>>>>>>
>>>>>>>
>>>>>>> Any ideas to address this? My current proposal is:
>>>>>>>
>>>>>>> - Return concept of groupId, which will return the path like
>>>>>>> "/qa/management". So usage could be like:
>>>>>>> Group qaGroup = new SimpleGroup("qa");
>>>>>>> Group qaManagementGroup = new SimpleGroup("management", qaGroup);
>>>>>>> assertEquals("management", qaManagementGroup.getName());
>>>>>>> assertEquals("/qa/management", qaManagement);
>>>>>>>
>>>>>>> - Either
>>>>>>> -- fix all existing usages of identityManager.getGroup(String groupId),
>>>>>>> so it really expects groupId as argument (not groupName):
>>>>>>>
>>>>>>> -- or introduce new method on IdentityManager (and IdentityStore) like:
>>>>>>>
>>>>>>> Group getGroupByGroupId(String groupId);
>>>>>>>
>>>>>>> It's possible that some identityStore implementations doesn't support
>>>>>>> groups with same name (For example current LDAPIdentityStore can't
>>>>>>> support it because there is only one DN for access all groups, but we
>>>>>>> discussed with Pedro that this is planned to address later)
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>> Marek
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev