"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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237819#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...