Novell Cool Solutions

Adding Objects as a Result of Another IDM Event



By:

February 27, 2008 7:33 am

Reads:4,632

Comments:0

Score:5

Print/PDF

In this article I describe two different scenarios. The first challenge was to automatically create a user when receiving an delete event for that user. The second scenario describes how to schedule a mass export of certain users from the IDVault.

Automatic Recreation

Once a customer asked me whether it is possible to restrict the deletion of synchronized objects in an application, with the help of an Identity Manager driver. The answer was “yes,” for sure. We implemented a policy that converts the delete to a remove-association and made a veto on the incoming delete. Then it was only a matter of time to wait for an event to resynchronize the user.

To speed this up, we send an email to the IDVault administrator. This was working fine, but the customer wanted the deleted users to be created at once through the policy. The main challenge was that the do-add-src-object action does not allow specifying any (mandatory) attribute of the object to be created, so a couple of additional do-add-src-attr-value actions were needed.

At the end, the policy looked like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policy PUBLIC "policy-builder-dtd" "/home/tschloesser/designer3/designer/eclipse/plugins/com.novell.designer.idm.policybuilder_2.0.0.200711271409/DTD/dirxmlscript.dtd"><policy>
  <rule>
    <description>Handle Delete Events</description>
    <comment xml:space="preserve">Removes Association, Recrates Object in AD and vetos the delete operation</comment>
    <conditions>
      <and>
        <if-operation mode="case" op="equal">delete</if-operation>
      </and>
    </conditions>
    <actions>
      <do-set-local-variable name="OldUserDN" scope="policy">
        <arg-string>
          <token-dest-attr name="DirXML-ADContext"/>
        </arg-string>
      </do-set-local-variable>
      <do-add-src-object class-name="user">
        <arg-dn>
          <token-dest-attr name="DirXML-ADContext"/>
        </arg-dn>
      </do-add-src-object>
      <do-set-src-attr-value class-name="user" name="description">
        <arg-dn>
          <token-local-variable name="OldUserDN"/>
        </arg-dn>
        <arg-value>
          <token-text xml:space="preserve">Recreated by IDM Policy</token-text>
        </arg-value>
      </do-set-src-attr-value>
      <do-set-src-attr-value class-name="user" name="givenName">
        <arg-dn>
          <token-local-variable name="OldUserDN"/>
        </arg-dn>
        <arg-value>
          <token-dest-attr class-name="user" name="Given name"/>
        </arg-value>
      </do-set-src-attr-value>
      <do-set-src-attr-value class-name="user" name="sn">
        <arg-dn>
          <token-local-variable name="OldUserDN"/>
        </arg-dn>
        <arg-value>
          <token-dest-attr class-name="user" name="Surname"/>
        </arg-value>
      </do-set-src-attr-value>
      <do-set-src-attr-value class-name="user" name="displayName">
        <arg-dn>
          <token-local-variable name="OldUserDN"/>
        </arg-dn>
        <arg-value>
          <token-dest-attr class-name="user" name="Surname"/>
          <token-text xml:space="preserve">, </token-text>
          <token-dest-attr name="Given Name"/>
        </arg-value>
      </do-set-src-attr-value>
      <do-remove-association>
        <arg-association>
          <token-association/>
        </arg-association>
      </do-remove-association>
      <do-veto/>
    </actions>
  </rule>
</policy>

Simply add as many additional do-add-sr-attr-value actions as needed. The policy can be used on other drivers as well, but then the value of the local variable OldUserDN must be changed to the full distinguished name of the former user object in the sending system.

Scheduled Export

In another project, the customer asked me whether it would be possible to have certain users with some attributes exported to a .csv file on a given schedule. At the time he was asking for it, it was not so easy to do this without external help; but since IDM 3.5 we have the job functionality that can be used in this case very well.

The idea was to use a scoped trigger job and a policy that is fired on each trigger event on the subscriber channel. The advantage of a scoped trigger job is that the configuration with which objects are to be exported is quite easy. As the scope definition can consist of individual objects, or containers and groups – both static and dynamic – it is easy to control later which objects are to be exported only by changing the scope, but not the policy.

The needed policy could look like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policy PUBLIC "policy-builder-dtd" "/home/tschloesser/designer3/designer/eclipse/plugins/com.novell.designer.idm.policybuilder_2.0.0.200711271409/DTD/dirxmlscript.dtd"><policy>
  <rule>
    <description>ExportOnTrigger</description>
    <conditions>
      <and>
        <if-operation mode="case" op="equal">trigger</if-operation>
        <if-xml-attr mode="nocase" name="source" op="equal">TriggerSynchronisation</if-xml-attr>
      </and>
    </conditions>
    <actions>
      <do-set-local-variable name="ObjectName" scope="policy">
        <arg-node-set>
          <token-xpath expression="@src-dn"/>
        </arg-node-set>
      </do-set-local-variable>
      <do-add-dest-object class-name="user">
        <arg-dn>
          <token-local-variable name="ObjectName"/>
        </arg-dn>
      </do-add-dest-object>
      <do-add-dest-attr-value class-name="user" name="Surname">
        <arg-dn>
          <token-local-variable name="ObjectName"/>
        </arg-dn>
        <arg-value>
          <token-src-attr class-name="user" name="Surname">
            <arg-dn>
              <token-local-variable name="ObjectName"/>
            </arg-dn>
          </token-src-attr>
        </arg-value>
      </do-add-dest-attr-value>
      <do-add-dest-attr-value class-name="user" name="Given Name">
        <arg-dn>
          <token-local-variable name="ObjectName"/>
        </arg-dn>
        <arg-value>
          <token-src-attr class-name="user" name="Given Name">
            <arg-dn>
              <token-local-variable name="ObjectName"/>
            </arg-dn>
          </token-src-attr>
        </arg-value>
      </do-add-dest-attr-value>
      <do-add-dest-attr-value class-name="user" name="Internet EMail Address">
        <arg-dn>
          <token-local-variable name="ObjectName"/>
        </arg-dn>
        <arg-value>
          <token-src-attr class-name="user" name="Internet EMail Address">
            <arg-dn>
              <token-local-variable name="ObjectName"/>
            </arg-dn>
          </token-src-attr>
        </arg-value>
      </do-add-dest-attr-value>
      <do-add-dest-attr-value class-name="user" name="Description">
        <arg-dn>
          <token-local-variable name="ObjectName"/>
        </arg-dn>
        <arg-value>
          <token-src-attr class-name="user" name="Description">
            <arg-dn>
              <token-local-variable name="ObjectName"/>
            </arg-dn>
          </token-src-attr>
        </arg-value>
      </do-add-dest-attr-value>
    </actions>
  </rule>
</policy>

In this example, only four fields will be exported: Given Name, Surname, email, and description. Feel free to include any attribute available in the ÍDVault.

To demonstrate the functionality I am including a modified delimited text driver configuration containing the job and the policy, as well as a revised output transformation style sheet that can create a .csv file with any number of attributes. So the number of fields in the .csv file depends only on the number of attributes you add in the policy.

2 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 5 (2 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...

Categories: Uncategorized

0

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

Comment

RSS