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 ?

Regards. Pedro Igor ----- Original Message ----- From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: security-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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

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

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.

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 ?

Regards. Pedro Igor ----- Original Message ----- From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: security-dev(a)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(a)redhat.com&gt; > To: security-dev(a)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(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

We discussed on irc with Pedro and for point 3, we choosed the approach that: IdentityManager.getGroup(String name) will return single group only if exactly one group of this name exists. If more groups with same name exists, it will throw exception. It seems that this won't affect existing applications and unit tests too much. There are also other approaches (return first found group, return null, search only 1st level groups (groups without parent)) but these seems to be more confusing or change existing behaviour. wdyt? Marek On 07/02/13 14:09, Pedro Igor Silva 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 > > 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); > > 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. > > 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 ? > > Regards. > Pedro Igor > > > ----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: security-dev(a)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(a)redhat.com&gt; >> To: security-dev(a)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(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

If I have /a /a/b /a/b/a /b /b/c/d IdentityManager.getGroup("d") would return me "/b/c/d" right?

To obtain /a should I use getGroup("a", null) ? On Feb 7, 2013, at 2:43 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > We discussed on irc with Pedro and for point 3, we choosed the approach > that: > > IdentityManager.getGroup(String name) > > will return single group only if exactly one group of this name exists. > If more groups with same name exists, it will throw exception. > > It seems that this won't affect existing applications and unit tests too > much. There are also other approaches (return first found group, return > null, search only 1st level groups (groups without parent)) but these > seems to be more confusing or change existing behaviour. > > wdyt? > Marek > > On 07/02/13 14:09, Pedro Igor Silva 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 >> >> 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); >> >> 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. >> >> 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 ? >> >> Regards. >> Pedro Igor >> >> >> ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> Cc: security-dev(a)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(a)redhat.com&gt; >>> To: security-dev(a)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(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

On 07/02/13 08:43, Marek Posolda wrote: > We discussed on irc with Pedro and for point 3, we choosed the approach > that: > > IdentityManager.getGroup(String name) > > will return single group only if exactly one group of this name exists. > If more groups with same name exists, it will throw exception. -1, this behaviour is inconsistent and should be avoided. We need to either add a "parent" parameter to the getGroup() method: getGroup(String name, Group parent) or pass in the fully qualified group name: getGroup(String groupPath) or both. > It seems that this won't affect existing applications and unit tests too > much. There are also other approaches (return first found group, return > null, search only 1st level groups (groups without parent)) but these > seems to be more confusing or change existing behaviour. > > wdyt? > Marek > > On 07/02/13 14:09, Pedro Igor Silva 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 >> >> 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); >> >> 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. >> >> 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 ? >> >> Regards. >> Pedro Igor >> >> >> ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> Cc: security-dev(a)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(a)redhat.com&gt; >>> To: security-dev(a)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

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

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.

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

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(a)redhat.com&gt; > 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

Marek, I do not think we agreed on maintaining backwards compatibility of IDM 3.x API with 2.x

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(a)redhat.com&gt; >> 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

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&gt; 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

+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&gt; >> 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

I also wonder about groups without hierarchy (no parent) scenario. If there should be null parent or some special root entity.