Static Assignments
./ldapsearch --port 1389 --hostname localhost --baseDN "dc=forgerock,dc=com" --bindDN "cn=directory manager" --bindPassword xxx --searchscope sub "(uid=user.10)" dn uid isMemberOf
dn: uid=user.10,ou=People,dc=forgerock,dc=com
uid: user.10
isMemberOf: cn=impersonation,ou=groups,dc=forgerock,dc=com
Once you remove the role, ldapsearch will validate that the group was deleted in DJ:
./ldapsearch --port 1389 --hostname localhost --baseDN "dc=forgerock,dc=com" --bindDN "cn=directory manager" --bindPassword xxx --searchscope sub "(uid=user.10)" dn uid isMemberOf
dn: uid=user.10,ou=People,dc=forgerock,dc=com
uid: user.10
Dynamic Assignments
Mapping called sourceLdapGroup_managedRole
The picture above shows which attributes to map for this particular mapping definition.
For the /attributes map, use the following transformation script:
([{assignmentOperation:'mergeWithTarget',unassignmentOperation:'removeFromTarget',name: 'ldapGroups',value: [ source.dn ]}])
This transformation script sets up the incoming group object as an OpenIDM assignment and also sets up the value of the "ldapGroups" attribute to the DN of the incoming group object.
For /roles, use this one:
([{_ref: 'managed/role/'+( openidm.query('managed/role',{'_queryFilter':'/name eq "' + source.cn + '"'}).result[0]._id)}])
This script queries the managed/role container in OpenIDM for a "named" provisioning role whose CN happens to equal the CN of the incoming group object. This assumes that you reconciled the managed/role objects first- and this is the only dependency for this use case. You cannot really search for a provisioning role's CN value before you reconcile it from LDAP. After retrieving the correct role object, the script sets the _ref property of the assignment to that particular provisioning role. This is what you would do if you were manually "attaching" a provisioning role to an assignment as shown in the Static Assignments section above.
Demo
Now it is a matter of running reconciliation on sourceLdapGroup_managedRole first, followed by running a reconciliation on sourceLdapGroup_managedAssignment. You should see roles such as:
And you should see assignments as well- these are basically "named" after the LDAP group objects that have an ldapGroup attribute setup and also an "attachment" setup to a provisioning role:
For example, lets look at the impersonation assignment in detail.
This picture shows the mapping for this assignment object, and the description reconciled from the OpenDJ groups org unit.
The picture below shows how the DN of the incoming LDAP group object was mapped to an attribute called "ldapGroups".
The picture below shows the provisioning role, with the same name of course, that is "attached" to this assignment object.
Now we have an "entitlement" framework for automatically creating assignment and role objects in OpenIDM using single or multiple "source" LDAP group containers, and then attaching these provisioning role objects to assignments. We have simply demonstrated a one-provisioning-role to one-assignment mapping in this use case, but far more complex mappings such as many-to-many or many-to-one are possible. This framework can serve as the foundation for an RBAC type scenario in your deployments! Good luck.