[security-dev] Group clarification

Anil Saldhana Anil.Saldhana at redhat.com
Thu Feb 7 14:24:02 EST 2013

   I do not think we agreed on maintaining backwards compatibility of 
with 2.x

This is a fresh effort.


On 02/07/2013 01:19 PM, Marek Posolda wrote:
> I agree with everything, Thanks!
> So in this case, we won't need new method
> identityManager.getGroupByPath(String), but we are changing the
> behaviour of existing method identityManager.getGroup(String), which
> previously expected groupName instead of groupId. So it looks like
> breaking of backwards compatibility, but maybe it's not so big issue at
> this stage (not sure if Aerogear or other projects are already using IDM
> 3.x, but hopefully nobody is using it in production now;)
> Thanks,
> Marek
> On 07/02/13 19: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

More information about the security-dev mailing list