[midPoint] Construct DN based on role
Jason Everling
jeverling at bshp.edu
Fri Jun 26 19:47:14 CEST 2015
So I have put together ours in a similar way, using the assigned orgs to
build the distinguishedName and place them in the correct ou/containers, I
attached some samples, cleaned up to remove our info,
JASON
On Fri, Jun 26, 2015 at 12:41 PM, Pavol Mederly <mederly at evolveum.com>
wrote:
> Hello Anton,
>
> one of options is to get a list of all the user assignments, and act on
> it. In a similar way that I wrote Roman today morning, i.e.
>
> <outbound>
> <strength>strong</strength>
> <source>
> <c:path>assignment</c:path>
> </source>
> <source> ....... any other sources, e.g. name, ... </source>
> <expression>
> <script>
> <relativityMode>absolute</relativityMode>
> <code>
> isStaff = false
> isAdmin = false
> ...
> log.info('assignment = {}', assignment) //
> assignment is a PrismContainer
> for (assignmentValue in assignment.getValues()) {
> log.info('checking {}', assignmentValue)
> targetRef =
> assignmentValue.asContainerable().getTargetRef()
> if (targetRef?.getOid()?.equals("....staff role OID....."))
> {
> isStaff = true
> } else if (targetRef?.getOid()?.equals("....admin role
> OID.....")) {
> isAdmin = true
> }
> ...
> }
>
> ... and now construct the DN based on isStaff, isAdmin etc.
>
> </code>
> </script>
> </expression>
> </outbound>
>
> I haven't actually tried it; but it could work.
>
> Another, and perhaps more elegant, way is to induce some user properties
> in the roles. E.g. admin role could put value of "Admin" to "employeeType"
> property. It would look like this:
>
> <role>
> <name>admin</name>
> <displayName>admin</displayName>
> <inducement>
> <focusMappings>
> <mapping>
> <expression>
> <value>Admin</value>
> </expression>
> <target>
> <path>employeeType</path>
> </target>
> </mapping>
> </focusMappings>
> </inducement>
> </role>
>
> And then you can use employeeType as just another source when constructing
> the user DN. Beware of situations when there would be more than one
> employeeType value (e.g. user would be both admin and let's say manager).
> Naive implementation of the mapping would yield to two DN's for the user.
>
> Maybe someone with more experiences in midPoint deployment (Ivan?) would
> improve these options a bit.
>
> Best regards,
> Pavol
>
>
> On 26. 6. 2015 19:08, midpoint at mybtinternet.com wrote:
>
> Hi,
>
> I have a role defined with an inducement for an Active Directory account
> and am able to successfully
> provision a basic account. However, I need the target container to be
> variable based on the user's
> role; e.g. staff goes to ou=staff,<directory-suffix> and admin users to
> ou=admin,<directory-suffix>.
>
> I was hoping to use ad_container in the role's inducement of the Active
> Directory account. The
> attempted provisioning fails with "Cannot represent container value
> without a parent as containerable".
>
> Also tried to find, unsuccessfully, references on how to programatically
> get the the user's role/s or
> assignments and then construct the DN based on values.
>
> Any suggestions?
>
> Thx,
> Anton
>
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential;
intended for only the recipient(s) named above and may contain information
that is privileged. You should not retain, copy or use this e-mail or any
attachments for any purpose, or disclose all or any part of the contents to
any person. Any views or opinions expressed in this e-mail are those of the
author and do not represent those of the Baptist School of Health
Professions. If you have received this e-mail in error, or are not the
named recipient(s), you are hereby notified that any review, dissemination,
distribution or copying of this communication is prohibited by the sender
and to do so might constitute a violation of the Electronic Communications
Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the
sender and delete this e-mail and any attachments from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleaned_ad_resource.xml
Type: text/xml
Size: 36378 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleaned_orgs.xml
Type: text/xml
Size: 13352 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meta_role_orgs.xml
Type: text/xml
Size: 1674 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org_template.xml
Type: text/xml
Size: 1887 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment-0003.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ad_user_template.xml
Type: text/xml
Size: 3036 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150626/417e2ad0/attachment-0004.xml>
More information about the midPoint
mailing list