[security-dev] Group clarification

[Anil Saldhana]

On 02/07/2013 01:31 PM, Marek Posolda wrote:
> 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...;-)
>
Software is like art or a sculpture.  There is always work because it is 
never done or perfect. :)


>>
>> 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