[midPoint] Creation order of ldap hierarchy

[Ivan Noris]

Hi Pertti,

use (provisioning) dependencies to create objects in order. Then assure
that you assign the roles and also set the assignment parameter at the
same time.


I'm using something like this for AD: each organization has assigned a
(meta)role which will create a part of organization hierarchy. Something
like this:

- ou=something

  - ou=municipalityname (kind: generic, intent: ou-municipality)

    - ou=computers (kind: generic, intent: ou-municipality-computers)

    - cn=group1municipalityname

    - cn=group2municipalityname

...


So in order to create groups or ou=computers, the upstream organization
ou=municipalityname must exist. The objects that must be created
together are configured as inducements in the (meta)role, the objectType
definitions for them are in schemaHandling in AD resource. If an object
must be created only after different object is created, <dependency>..
can be used to specify the object (kind, intent, even resourceRef - not
used here).


Resource schema handling (fragments):

...

        <objectType>
            <kind>generic</kind>
*            <intent>ou-municipality</intent>*
            <displayName>Organizational Unit</displayName>
            <description>Organizational unit for obec</description>
           
<objectClass>ri:CustomorganizationalUnitObjectClass</objectClass>
            <attribute>
                <ref>icfs:name</ref> <!-- required attribute on AD -->
                <matchingRule>mr:stringIgnoreCase</matchingRule>
                <outbound>
                    <source>
                        <path>$focus/name</path>
                    </source>
                    <expression>
                        <script>
                            <code>
tmpSuffix = basic.getResourceIcfConfigurationPropertyValue(resource,
'Container')
'OU=' + name + ',' + tmpSuffix
</code>
                        </script>
                    </expression>
                </outbound>
            </attribute>
...

        </objectType>


        <objectType>
            <kind>generic</kind>
*            <intent>ou-municipality-computers</intent>*
            <displayName>Organizational Unit - Computers</displayName>
            <description>Organizational unit for municipality -
computers</description>
            <default>false</default>
           
<objectClass>ri:CustomorganizationalUnitObjectClass</objectClass>
            <attribute>
                <ref>icfs:name</ref> <!-- required attribute on AD -->
                <matchingRule>mr:stringIgnoreCase</matchingRule>
                <outbound>
                    <source>
                        <path>$focus/name</path>
                    </source>
                    <expression>
                        <script>
                            <code>
tmpSuffix = basic.getResourceIcfConfigurationPropertyValue(resource,
'Container')
'OU=Computers,OU=' + name + ',' + tmpSuffix
</code>
                        </script>
                    </expression>
                </outbound>
            </attribute>
...

*            <dependency>**
**                <kind>generic</kind>**
**                <intent>ou-municipality</intent>**
**                <strictness>relaxed</strictness>**
**            </dependency>**
*    </objectType>
...


Role:


<role ...>

  <name>Org metarole</name>

    <inducement>
        <construction>
            <!-- AD resource -->
            <resourceRef oid="00000000-dc00-dc00-0001-100000000002"
type="c:ResourceType"/>
            <kind>generic</kind>
                <intent>ou-municipality-computers</intent>
        </construction>
    </inducement>

    <inducement>
        <construction>
            <!-- AD resource -->
            <resourceRef oid="00000000-dc00-dc00-0001-100000000002"
type="c:ResourceType"/>
            <kind>generic</kind>
                <intent>ou-municipality</intent>
        </construction>
    </inducement>
...

</role>


The role itself does not specify anything about ordering, it just says
that the objects should be provisioned together. Resource schemaHandling
contains the dependency ordering. "relaxed" means that if the objects
should be created in the same operation (via my role), they should be
provisioned in order. $focus/name correspond to the organization name
which is assigned the (meta)role and for which is provisioning running.


You can chain the objects as you wish, just do not create circular
dependency. I'm using this setup to create 20-25 projections for an
organization using multiple subtrees.


In your case I assume that you will have two inducements in the role -
one for creating ou=org,... and one for creating a group in the org. So
you will need at least two objectType definitions in schemaHandling. If
the object name is constructed from the assignment parameter,
icfs:name/ri:dn should be probably constructed in the mapping in the
role itself.


Reverse order is used for deleting objects.


Hope this helps,

Ivan



On 11/21/2016 07:00 PM, Pertti Kellomäki wrote:
>
> Hi,
>
>
> I am creating ldap groups based on midPoint roles. The name of the
> group is based on the name of the role, and the organizational unit
> given in the assignment when the role is assigned to a user. So
> something like this:
>
>
>   cn=role1,ou=org1,ou=Groups
>
>   cn=role1,ou=org2,ou=Groups
>
>
> At some point I need to create the ou's org1 and org2 in ldap. Do I
> run into ordering problems if I put both the creation of the ou in
> ldap, and the creation of the ldap group as inducements in the same
> role? Or should the creation of the organizational units in midPoint
> already trigger creation of the ou's in ldap so that the ou is
> guaranteed to exist in ldap when the role is assigned?
>
>
> Pertti
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-- 
Ivan Noris
Senior Identity Engineer
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161121/a701264d/attachment.htm>