Re: [security-dev] Group clarification

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