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(a)redhat.com>
To: security-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/security-dev
>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev