[security-dev] Group clarification

[Marek Posolda]

On 07/02/13 20:24, Anil Saldhana wrote:
> Marek,
>     I do not think we agreed on maintaining backwards compatibility of
> IDM 3.x API
> with 2.x
Yes, I meant that existing applications, which are already using IDM 
3.x, will be affected because it's change in behaviour of method 
identityManager.getGroup(String)

However I hope there are not so much such applications at this stage, so 
probably it's not big deal...;-)

Marek
>
> This is a fresh effort.
>
> Regards,
> Anil
>
> 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
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev