&quot;tom.baeyens(a)jboss.com&quot; wrote : "bdaw" wrote : Maybe it would make sense to let use those information in API more directly? Something like: | | - associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName) | | | | exactly. the default case should be a one-to-one mapping between the api-ID and the phisical identityStore-ID. | Here you mean the same like it is now? Not sure if I understand this part correctly &quot;tom.baeyens(a)jboss.com&quot; wrote : | only if the user wants to bind to some exotic identity store, then a mapping between the API-ID strings and the identity store IDs might be necessary. the API/SPI architecture would still allow that. | Open question is how to put changes into the API. So for egz. Approach A) We make methods duplicates like the one I described above whenever possible to use type/name information. One problem here is that for methods like: | void associateIdentities(Collection<Group> parents, Collection<Identity> members) | it's hard to find handy alternative :) Approach B) We have Identity.getId() and Group.getId() but the actual content of the returned String is some encoded value like [typeName];[name];[store_internal_id]. Last part could be optional Then we can utilize String like ID more in methods but main problem is that format can't be final - it shouldn't be allowed to assemble such id manually. It would require some dedicated method. Format can utilize something like basic xml to encode information. Then minimal required ID content would be name/type pair. Other info like realm id, repository id, store id and true object id inside the store is optional and applied by the SPI. Would it make sense? Something like | String PersistenceManager.getIdentityId(String name); | String PersistenceManager.getGroupId(String name, String type); | Then we make another version of methods with String ids like: | void associateGroupsAndIdentities(Collection<String> parentGroupIDs, Collection<String> memberIdentityIDs) | How does it look like? Obviously we could have both A) and B) concept. The main limitation here is to not triple number of methods.... &quot;tom.baeyens(a)jboss.com&quot; wrote : | i would even make the groupTypes plain strings in the api. | Indeed. In current shape both GroupType and RoleType could be changed into plain String . Other similar one is CredentialType but because of how Credential is implemented it can be left like this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209611#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...