[security-dev] Group clarification

[Boleslaw Dawidowicz]

On Feb 7, 2013, at 2:09 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Ok. I think we can add this for groups, as you pointed out.
> 
> The rule would be:
> 
>    1) You can not add two groups without parent and with the same name;
> 
>         identityManager.add(new SimpleGroup("management"));
> 
>         identityManager.add(new SimpleGroup("management")); // should fail

+1

> 
>    2) You can add two groups with the same name but different parents;
> 
>         identityManager.add(new SimpleGroup("management", qaGroup));
> 
>         identityManager.add(new SimpleGroup("management"), devGroup);

+1

> 
>    3) The IdentityManager.getGroup(String name) will return only one group with the specified name with no parent. Or with parent if only one exists with the given name.

You need a concept of root "/" so it would return group with id like "/name" 

> 
>    4) The IdentityManager.getGroup(String name, Group parent) will return only one group with the specified name and parent; 
> 
>    5) If you need all groups with can use the Query API.
> 
>    6) I think we can add the method getGroupByGroupId (maybe rename it to getGroupByPath).
> 
> Wdyt ?
> 

I think it makes sense. 

Please remember that this is not really "portal" requirement. This is "enterprise LDAP" requirement. 

Default LDAP store implementation that maps roles in specify way defined by us can be neat for small projects and demos. For real life scenario when you need to integrate LDAP you always have enforced tree shape preloaded with lot of data. So in 99% cases you cannot enhance the schema or alter the tree. What Marek described:

/dev/management
/qa/management

can be fairly typical case - not those exact group names but tree shape with repeating group naming.

API model needs to be able to handle it. LDAP IdentityStore implementation will need to be flexible enough to adapt to already populated directory stores like this if it is supposed to be useful. 

And again… this requirement came from portal but it is NOT portal requirement. It is real life and most typical integration scenario everywhere around :)


> Regards.
> Pedro Igor
> 
> 
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Thursday, February 7, 2013 10:51:50 AM
> Subject: Re: [security-dev] Group clarification
> 
> On 07/02/13 13:20, Pedro Igor Silva wrote:
>> I understood your point. Maybe you can use partitions and have something like that:
>> 
>>     - Partition QA (Realm or Tier)  -> Group Management
>> 
>>     - Partition DEV (Realm or Tier) -> Group Management
>> 
>> Or you really need groups with same name ?
> yes, it's one of requirements. In portal we are using realms for 
> different portal organizations (portal containers). But there is still 
> possibility to have groups with same name withing single realm (you 
> can't have two children groups called "management" as children of same 
> parent group, but you can have two "management" groups if both have 
> different parent group).
> 
> If I remember correctly, GateIn didn't support this in early stages few 
> years ago, but we added it because it was feature request required by 
> customers.
> 
> Regards,
> Marek
>> 
>> Regards.
>> Pedro Igor
>> 
>> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: security-dev at lists.jboss.org
>> Sent: Thursday, February 7, 2013 10:02:18 AM
>> Subject: [security-dev] Group clarification
>> 
>> 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