[security-dev] Group clarification

[Bolesław Dawidowicz]

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.

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
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>