Hi Anil,
We discussed yesterday a bit with Pedro. PL IDM 1.x supports that some
part of the group tree is mapped to some Ldap DN and different part is
mapped to other DN.
For example:
All Subgroups of group "/org" are mapped to
"ou=Qa,o=something,dc=jboss,dc=org"
And all subgroups of group "/differentOrg" are mapped to
"ou=DifferentOrg,o=something,dc=jboss,dc=org"
This mapping is specified in idm 1.x configuration file. So
configuration could look like:
"/org/*" -> "ou=org,o=something,dc=jboss,dc=org"
"/differentOrg/*" -> "ou=differentOrg,o=something,dc=jboss,dc=org"
Wit this configuration, the top group itself like "/org" is saved in
default identity store (usually DB) but subgroups are stored in LDAP. So
for example group "/org/users" is saved in LDAP as
"cn=users,ou=org,o=something,dc=jboss,dc=org"
So in 1.x there is restriction that groupName needs to be unique for
each part of Ldap tree. So you can have group "/org/a" and
"/differentOrg/a". But you can't have "/org/a" and
"/org/something/a"
(Two groups with name "a" can't be under "/org" subtree)
Regards,
Marek
On 08/02/13 00:36, Anil Saldhana wrote:
How does the LDAP DIT look like (for same groups different parents)
in
PL IDM 1.x?
On 02/07/2013 02:11 PM, Bolesław Dawidowicz wrote:
> +1
>
> On 02/07/2013 08:34 PM, Shane Bryzak wrote:
>> This looks good.
>>
>> On 07/02/13 13: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(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