-
1. Re: GroupId or (groupName & GroupType)
tom.baeyens Jun 16, 2009 3:26 AM (in response to jeff.yuchang)"jbpid_group_id_._._unit_._._sales-dept" is a very nasty id that you generate.
so the real point is actually: shouldn't we switch to user-provided id's for the groups as well. just like we do with the users ?
what was the reason that we didn't do that ? -
2. Re: GroupId or (groupName & GroupType)
jeff.yuchang Jun 16, 2009 4:12 AM (in response to jeff.yuchang)"tom.baeyens@jboss.com" wrote:
"jbpid_group_id_._._unit_._._sales-dept" is a very nasty id that you generate.
so the real point is actually: shouldn't we switch to user-provided id's for the groups as well. just like we do with the users ?
what was the reason that we didn't do that ?
I think we can have an approach to this issue.
we will use what it uses for groupId, candidate-group now. but we need to document the format for this groupId:
it is:String groupId = groupType != null ? groupType + "." + groupName : groupName;
in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.
In this case, we don't need to make any changes, the only one thing is just to document it?
What do you think?
-Jeff -
3. Re: GroupId or (groupName & GroupType)
kukeltje Jun 16, 2009 4:52 AM (in response to jeff.yuchang)"jeff.yuchang" wrote:
in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.
In this case, we don't need to make any changes, the only one thing is just to document it?
What do you think?
I don't think large (or even small) companies are going to switch to adapting their IDM (or more complex IAM systems) to conform to this jBPM requirement. No way. A real life example:
In an LDAP we used, the groupname was the CN, the real id is the DN, which was composed of the CN, O and C filed. How could this be adapted to the jBPM id format. In addition.
In another situation there was an additional OU in between which could also be used as a group when the users below the OU are seen as part of the group. How would the 'id' fit in here?
Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations. -
4. Re: GroupId or (groupName & GroupType)
jbarrez Jun 16, 2009 4:56 AM (in response to jeff.yuchang)+1
I don't think large (or even small) companies are going to switch to adapting their IDM (or more complex IAM systems) to conform to this jBPM requirement.
I agree. Users have the strangest IDM mappings in place, I've seen my share of strange, legacy stuff.
By not constraining the assignment strings in the jpdl file, people can do whatever they want, which is the best solution, imo. -
5. Re: GroupId or (groupName & GroupType)
bdaw Jun 16, 2009 5:10 AM (in response to jeff.yuchang)In JBoss IDM when you plug LDAP you point groupType to a specific tree part. Then you would refer to configured groupType and simply use the CN part as groupID. Id needs to be unique in scope of groupType so this fits.
I think jbpm could allow non constrained ids and just force composite ids for idm integration. then in situation when you plag few different identity stores and map group types to them you need to have some way to discover where they belong anyway. And groupType in composite key allows this. -
6. Re: GroupId or (groupName & GroupType)
jeff.yuchang Jun 16, 2009 5:38 AM (in response to jeff.yuchang)"kukeltje" wrote:
Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations.
Thanks for the info, yes, this is a totally valid point.. now I see the bad result of imposing constraints on the groupId.
;-)
thanks
Jeff