The Roles Based Provisioning Module for NetIQ Identity Manager has a number of components. There is workflow definitions, the end user web interface itself, and the Roles & Resources engine.

It is a little unclear from the surface how this all fits together so I thought I would take practical example I ran into at work one day, and walk through the various parts to provide some examples, and hints for further troubleshooting.

First off there are a number of moving parts. The User Application is meant to be the agent for enaction of Role and Resource granting requests. Whether you do it as a human through the web interface in the Roles or Resources Catalog, via a Workflow request, or through the SOAP Web Service it still all flows through the User Application.

The end result of the User App generating a request for a Role or Resource grant is the creation of an nrfRequest object in a container under the User App driver in eDirectory. The DN from the first example is:

\TEST_IDM\acme\services\driverSet\UserApplication\AppConfig\RoleConfig\Requests\20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0

That is, under the UserApplication driver object, there is an AppConfig container object that a lot of the User Application configuration and 'stuff' is stored. The Roles and Resource definitions are stored as objects under here, and much more.

In this case, in the container under AppConfig of: RoleConfig\Requests

The CN of the nrfRequest object is:

20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0

The CN consists of a date stamp, followed by a GUID, followed by a zero. I am not sure what the 0 indicates, other than perhaps to allow more than one request for one object within the second granularity of the timestamp, so you can avoid naming collisions for many events for one object at a time. Though I am not so sure, since I think the GUID is of the entry in the database for the request as opposed to the User involved's GUID. But I am not certain.

To some extent creating the nrfRequest object is the end of the User Apps direct interaction with the process for now. Instead, this event is seen by the Roles and Resources Services Driver (RRSD) driver. Prior to the addition of the Resource abstraction in User App 3.7, there was the Roles Services Driver (RSD) that did much the same but only for Role objects, since Resource objects did not exist.

The RRSD driver reacts to the nrfRequest create event:

[08/29/13 09:37:42.382]:roles ST:Processing events for transaction.
[08/29/13 09:37:42.383]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <add cached-time="20130829133742.297Z" class-name="nrfRequest" event-id="acme01#20130829133742#4#1:6552ed12-b833-4177-7495-12ed526533b8" qualified-src-dn="O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0" src-dn="\TEST_IDM\acme\services\driverSet\UserApplication\AppConfig\RoleConfig\Requests\20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0" src-entry-id="96775" timestamp="1377783462#13">
      <add-attr attr-name="nrfStatus">
        <value timestamp="1377783462#13" type="int">0</value>
      </add-attr>
    </add>
  </input>
</nds>

The policy object NOVLRSERVB-sub-etp has a rule named "Convert the event into a custom command to send to the driver" that converts that to this event:

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:request dn="O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>

The shim gets the event and tells us:

[08/29/13 09:37:42.406]:roles ST:Submitting document to subscriber shim:
[08/29/13 09:37:42.406]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:request dn="O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0" event-id="0" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>
[08/29/13 09:37:42.411]:roles ST:: Processing request
        DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0
[08/29/13 09:37:42.474]:roles ST:: Process Equivalent To Me
                Role: Process Equivalent To Me
                Role: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
                Operation: 5
                Identity: O=acme\OU=Users\OU=Empl\CN=jsmith
                Operation: {1}
                Identity: {2}
[08/29/13 09:37:42.479]:roles ST:: Retrieving resource association objects based on a role or resource DN. DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
[08/29/13 09:37:42.523]:roles ST:SubscriptionShim.execute() returned:
[08/29/13 09:37:42.524]:roles ST:
<nds dtdversion="3.6.1">
  <source>
    <product instance="Role and Resource Service Driver" version="4.0.0.5730">Novell Role Service Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="0" level="success">Transitioned request status from 0 to 30
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0</status>
    <status event-id="0" level="success">Added assigned role to identity
                Role: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
                Identity: O=acme\OU=Users\OU=Empl\CN=jsmith</status>
    <status event-id="0" level="success">Created resource request
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20130829093742-ed54c0d908a94d179355159fdced39fb-0</status>
    <status event-id="0" level="error">Error creating resource request
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20130829093742-ed54c0d908a94d179355159fdced39fb-0
                Reason: java.lang.Exception: Error. Entitlement parameter value is not in the expected JSON format, defined by the entitlement configuration setting named parameter-format.  This can occur from malformed JSON in the parameter value, or an entitlement was provisioned with a legacy parameter value before the entitlement parameter support was upgraded to IDM4.
                DN: O=acme\OU=services\CN=driverSet\CN=SAP Portal Testing\CN=UserAccount
                Agent: UA
                Parameter Value: %EntitlementParamKey%</status>
    <status event-id="0" level="error">Unable to add assigned role to identity
                Role: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
                Identity: O=acme\OU=Users\OU=Empl\CN=jsmith
                Reason: java.lang.Exception: Error. Entitlement parameter value is not in the expected JSON format, defined by the entitlement configuration setting named parameter-format.  This can occur from malformed JSON in the parameter value, or an entitlement was provisioned with a legacy parameter value before the entitlement parameter support was upgraded to IDM4.
                DN: O=acme\OU=services\CN=driverSet\CN=SAP Portal Testing\CN=UserAccount
                Agent: UA

                Parameter Value: %EntitlementParamKey%</status>
    <status event-id="0" level="success">Transitioned request status from 30 to 80
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0</status>
  </output>
</nds>
[08/29/13 09:37:42.538]:roles ST:No input transformation policies.
[08/29/13 09:37:42.538]:roles ST:No schema mapping policies.
[08/29/13 09:37:42.538]:roles ST:Resolving association references.
[08/29/13 09:37:42.539]:roles ST:Processing returned document.
[08/29/13 09:37:42.539]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.539]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Transitioned request status from 0 to 30
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0
[08/29/13 09:37:42.542]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.542]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Added assigned role to identity
                Role: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
                Identity: O=acme\OU=Users\OU=Empl\CN=jsmith
[08/29/13 09:37:42.545]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.545]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Created resource request
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20130829093742-ed54c0d908a94d179355159fdced39fb-0
[08/29/13 09:37:42.547]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.548]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Error
     Message:  Error creating resource request
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20130829093742-ed54c0d908a94d179355159fdced39fb-0
                Reason: java.lang.Exception: Error. Entitlement parameter value is not in the expected JSON format, defined by the entitlement configuration setting named parameter-format.  This can occur from malformed JSON in the parameter value, or an entitlement was provisioned with a legacy parameter value before the entitlement parameter support was upgraded to IDM4.
                DN: O=acme\OU=services\CN=driverSet\CN=SAP Portal Testing\CN=UserAccount
                Agent: UA
                Parameter Value: %EntitlementParamKey%
[08/29/13 09:37:42.551]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.551]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Error
     Message:  Unable to add assigned role to identity
                Role: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-Portal-ECC-AccountRole
                Identity: O=acme\OU=Users\OU=Empl\CN=jsmith
                Reason: java.lang.Exception: Error. Entitlement parameter value is not in the expected JSON format, defined by the entitlement configuration setting named parameter-format.  This can occur from malformed JSON in the parameter value, or an entitlement was provisioned with a legacy parameter value before the entitlement parameter support was upgraded to IDM4.
                DN: O=acme\OU=services\CN=driverSet\CN=SAP Portal Testing\CN=UserAccount
                Agent: UA
                Parameter Value: %EntitlementParamKey%
[08/29/13 09:37:42.555]:roles ST:Processing operation <status> for .
[08/29/13 09:37:42.555]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\acme\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Transitioned request status from 30 to 80
                DN: O=acme\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829093826-2b9e8798e7e047a6a5a15b167108f79b-0
[08/29/13 09:37:42.559]:roles ST:End transaction.

You can see that I got an error in this case, specifically:

Reason: java.lang.Exception: Error. Entitlement parameter value is not in the expected JSON format, defined by the entitlement configuration setting named parameter-format. This can occur from malformed JSON in the parameter value, or an entitlement was provisioned with a legacy parameter value before the entitlement parameter support was upgraded to IDM4.

What happened is that I was fiddling with a driver configuration I did not 100% understand, and the entitlement objects in that configuration did not define the entitlements as using the Legacy Entitlement parameter format, instead of the IDM 4, entitlement parameter format.

The DirXML-EntitlementRef is a very interesting attribute that uses Path syntax (Like DirXML-Associations), but with a twist. Path syntax consists of a component named nameSpace, which is an integer, where 0 means revoked, 1 means granted. Then there is the volume component which contains the DN reference to the DirXML-Entitlement object being granted. Finally there is a string component named simply path, but the twist is that it is in fact path.xml and the string must be valid XML. There is a really interesting error if you set a value that is NOT valid XML on any function that processes it. Alas, I never quite recorded the error to my regret.

Anyway, the path.xml component is meant to carry the payload of the entitlement grant, and in fact, the Entitlement tokens (If Entitlement (condition), Removed Entitlement (noun), Added Entitlement (noun)) generally treat the path.xml component, specifically the <param> node in there, as 'current-node' if you loop over the values.

Thus the 'value' of an entitlement according to the tokens, is the <param> node of the path.xml.

In IDM 3.6 there was only a single value supported in the param node. In IDM 3.61 to support the fanout SAP User driver configuration, where the name of the system, and the user name were required, something needed to be done. Without changing the engine simplest solution was to just use the pipe symbol (|) to delimit key value pairs. So LSNAME=SRMCLNT100|CTYPE=cua would provide two keys (LSNAME and CTYPE) with values.

Parsing this up, was an ECMA function, included in the Lib-AJC ECMA library. This was the format I was passing into the entitlement parameter. However, the engine in IDM 4 added a new format, using JSON notation. That would look more like {"LSNAME":"SRMCLNT100","CTYPE":"cua"} instead. Again they updated the ECMA function to handle either the pipe delimited function or the JSON version. Which is quite nice, as on the Policy end, using the ECMA functions, you can just use one call, and it returns the values which ever way they are encoded. Go look at the ECMA of how they did it, it is kind of clever.

However, the RRSD driver, is hard coded to look for the format it is expecting, and it was expecting JSON and did NOT like the grant in the pipe delimited format as you can see from the error message. So how does it know what to expect? Well the answer there is in the entitlementConfiguration object that each driver needs to have to enable Resource support. With the User App 3.70 release, that introduced Resources to the model, as an abstraction for Entitlements, they required this new DirXML-Resource object, with a DirXML-ContentType set to: text/vnd.novell.idm.entitlementConfiguration xml

When the User App does a CODE MAP refresh, (I have another article under construction, that discusses how to troubleshoot and understand what is happening in a CODE MAP refresh event, so stay tuned for that) it reaches out to each driver in the driver set. (Though I am not sure if it tries all driver in all driver sets, I almost always use just a single driver set these days). It queries the entitlementConfiguration objects, and reads the XML Out of there.

All modern drivers include an Input Transform Policy that reads some GCVs and builds the entitlementConfiguration object on each driver restart for you. This includes a setting, as the error notes, called 'parameter-format' that is either legacy of IDM4 and defines whether to expect pipe separated or JSON format. So in my case, the driver was 'configured' to use JSON format, but I granted an entitlement value that was not JSON.

Fixing the error was as simple as editing the entitlementConfiguration object and changing the format. In my case, I was testing what I thought was a bug, so I disabled the ITP rule that regenerates it all the time, and hard coded some values by hand. Otherwise, I would have changed the GCV for the entitlement to say use legacy format, and just restarted the driver.

Once I changed the format, made another attempt, changed the Entitlement to not need any parameters, since they were not needed really and got this result:

[08/29/13 10:12:31.159]:roles ST:Start transaction.
[08/29/13 10:12:31.160]:roles ST:Processing events for transaction.
[08/29/13 10:12:31.161]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <add cached-time="20130829141231.090Z" class-name="nrfRequest" event-id="tstidm01#20130829141231#4#3:6552ed12-b833-4177-7495-12ed526533b8" qualified-src-dn="O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0" src-dn="\TEST_IDM\tstidm\services\driverSet\UserApplication\AppConfig\RoleConfig\Requests\20130829101315-a2791e4959e243a2bf854146eeb6d308-0" src-entry-id="96788" timestamp="1377785551#24">
      <add-attr attr-name="nrfStatus">
        <value timestamp="1377785551#24" type="int">0</value>
      </add-attr>
    </add>
  </input>
</nds>

This becomes the command to the driver:

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:request dn="O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>

Returned by the RRSD is the result:

[08/29/13 10:12:31.185]:roles ST:: Processing request
        DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0
[08/29/13 10:12:31.194]:roles ST:: Retrieving resource association objects based on a role or resource DN. DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-UM-BW-AccountRole
[08/29/13 10:12:31.205]:roles ST:SubscriptionShim.execute() returned:
[08/29/13 10:12:31.205]:roles ST:
<nds dtdversion="3.6.1">
  <source>
    <product instance="Role and Resource Service Driver" version="4.0.0.5730">Novell Role Service Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="0" level="success">Transitioned request status from 0 to 30
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0</status>
    <status event-id="0" level="success">Added assigned role to identity
                Role: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-UM-BW-AccountRole
                Identity: O=tstidm\OU=Users\OU=Empl\CN=jsmith</status>
    <status event-id="0" level="success">Transitioned request status from 30 to 50
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0</status>
  </output>
</nds>
[08/29/13 10:12:31.209]:roles ST:No input transformation policies.
[08/29/13 10:12:31.209]:roles ST:No schema mapping policies.
[08/29/13 10:12:31.209]:roles ST:Resolving association references.
[08/29/13 10:12:31.209]:roles ST:Processing returned document.
[08/29/13 10:12:31.210]:roles ST:Processing operation <status> for .
[08/29/13 10:12:31.210]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\tstidm\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Transitioned request status from 0 to 30
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0
[08/29/13 10:12:31.211]:roles ST:Processing operation <status> for .
[08/29/13 10:12:31.212]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\tstidm\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Added assigned role to identity
                Role: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level10\CN=SAP-UM-BW-AccountRole
                Identity: O=tstidm\OU=Users\OU=Empl\CN=jsmith
[08/29/13 10:12:31.213]:roles ST:Processing operation <status> for .
[08/29/13 10:12:31.213]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\tstidm\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Transitioned request status from 30 to 50
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=Requests\CN=20130829101315-a2791e4959e243a2bf854146eeb6d308-0

Here you get a successful transition of the Role grant from 0 to 30. Then 30 to 50 which is completed. It would be nice to understand what the various status levels means. I have seen numerous different values, but they are not well documented to my liking. Alas.

I find it very helpful to see what a successful event looks like, so that I know when my actual event differs, where it went wrong, and that often can help me figure out where to look next. I am not aware of any good examples of how the RRSD trace looks anywhere else, so I hope this simple example offers a useful sample to folk who encounter issues they need to work through.

Next up, I thought it would be interesting to see what the trace looks like for delete a role assignment object. In general you would not be doing this, but since I did, and it ran through my driver, it is worth recording somewhere. I was cleaning up a mess I had made, with a bad request (see error above) that would not otherwise clean itself up.

[08/31/13 00:02:17.117]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <delete cached-time="20130831040213.818Z" class-name="nrfResourceRequest" event-id="tstidm01#20130831040213#4#51:e53057a4-008c-457a-2994-a45730e58c00" qualified-src-dn="O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20130624180524-cecddaaef1074ff2b2efe0f3b3bdd81f-0" src-dn="\TEST_IDM\tstidm\services\driverSet\UserApplication\AppConfig\RoleConfig\ResourceRequests\20130624180524-cecddaaef1074ff2b2efe0f3b3bdd81f-0" src-entry-id="56732" timestamp="1372111524#143"/>
  </input>
</nds>

And the answer to what happens in this case, is that it vetos out:

[08/31/13 00:02:17.295]:roles ST:    Applying rule 'Ignore everything except add, modify, and sync for all classes'.
[08/31/13 00:02:17.296]:roles ST:      Action: do-veto().

Next, since the object is deleted, DN references to the object fade away as we see in this nrfMemberOf attribute on a user assigned the role change as the next event. It is worth mentioning, that in olden days, deleting an object referenced by many hundreds of thousands of objects (Say a Driver object, with one hundred thousand associated objects) could lock eDirectory, fatally. This has been resolved many years ago, and eDir 8.8 and family are all fine with that. But there was a time, where it would cause ndsd to run at 100% for a very long time trying to clean that all up.

Here we have the remove value of the nrfMemberOf attribute, since the DN it points at no longer exists, the attribute value must go away:

[09/03/13 10:05:08.736]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <modify cached-time="20130903140508.670Z" class-name="User" event-id="tstidm01#20130903140504#4#2:5e321e8a-a099-41c9-dd85-8a1e325e99a0" qualified-src-dn="O=tstidm\CN=jsmith" src-dn="\TEST_IDM\tstidm\jsmith" src-entry-id="49636" timestamp="0#0">
      <modify-attr attr-name="nrfMemberOf">
        <remove-value>
          <value timestamp="1372110082#161" type="dn">\TEST_IDM\tstidm\services\driverSet\UserApplication\AppConfig\RoleConfig\RoleDefs\Level10\SAP-Portal-ECC-AccountRole</value>
        </remove-value>
      </modify-attr>
    </modify>
  </input>
</nds>

This gets mapped to a command to the driver that looks like:

[09/03/13 10:05:08.753]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:identity dn="O=tstidm\CN=jsmith" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>
[09/03/13 10:05:08.754]:roles ST:Subscriber processing identity for .
[09/03/13 10:05:08.754]:roles ST:Submitting unknown event to subscriber shim.
[09/03/13 10:05:08.755]:roles ST:No command transformation policies.
[09/03/13 10:05:08.755]:roles ST:Filtering out notification-only attributes.
[09/03/13 10:05:08.755]:roles ST:Fixing up association references.
[09/03/13 10:05:08.755]:roles ST:No schema mapping policies.
[09/03/13 10:05:08.755]:roles ST:No output transformation policies.
[09/03/13 10:05:08.756]:roles ST:Submitting document to subscriber shim:
[09/03/13 10:05:08.756]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:identity dn="O=tstidm\CN=jsmith" event-id="0" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>
[09/03/13 10:05:08.757]:roles ST:: Recalculating roles for identity: O=tstidm\CN=jsmith
[09/03/13 10:05:08.876]:roles ST:SubscriptionShim.execute() returned:
[09/03/13 10:05:08.876]:roles ST:
<nds dtdversion="3.6.1">
  <source>
    <product instance="Role and Resource Service Driver" version="4.0.0.5730">Novell Role Service Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="0" level="success">nrf:identity: O=tstidm\CN=jsmith</status>
  </output>
</nds>

Seems like this just tells the RRSD driver to go re-evaluate the user in general, rather than a specific command to remove or add some specific value. This is probably a good thing. One of the things that bothers me with the Roles and Resource model is that it uses what is basically static inheritance. That is, if you grant a Role to an Organizational Unit, it will add the nrfAssociatedRoles to the container, and then go stamp all child objects with nrfInheritedRoles or the like. I.e. Statically define it on every child object. I wish they could have chosen a model that followed the eDirectory inheritance model. I am not sure entirely how, but think it would be better to NOT statically stamp all the objects.

However, once you have this static model, you really have little choice but to watch for events that might affect the end state of a particular user (or all children of a container) and go reevaluate all of the possible outcomes, and update as needed.

Eventually in the clean up, we get to the resource assignment being removed:

[09/03/13 10:06:08.672]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <modify cached-time="20130903140508.705Z" class-name="nrfResourceAssociation" event-id="tstidm01#20130903140508#4#39:5e321e8a-a099-41c9-dd85-8a1e325e99a0" qualified-src-dn="O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20130830154944-7ed335ed4b91425285140a75fbc2c390" src-dn="\TEST_IDM\tstidm\services\driverSet\UserApplication\AppConfig\RoleConfig\ResourceAssociations\20130830154944-7ed335ed4b91425285140a75fbc2c390" src-entry-id="108947" timestamp="0#0">
      <modify-attr attr-name="nrfRole">
        <remove-value>
          <value timestamp="1377892139#4" type="dn">\TEST_IDM\tstidm\services\driverSet\UserApplication\AppConfig\RoleConfig\RoleDefs\Level10\SAP-Portal-ECC-AccountRole</value>
        </remove-value>
      </modify-attr>
    </modify>
  </input>
</nds>

So this is a case, where the nrfRole attribute is being removed from the nrfResourceAssociation object. Again, this use of another object to link two objects together really looks like a database guy tried to map database approaches to a directory service. Would be nice to for them to remember it is a directory we are using here, and not a database, and there are directory ways to do things that can be efficient that are not available in a database.

This event gets mapped to the command. I should note that I keep saying the 'event gets mapped' because in fact, if you read the policy, you will see it uses a mapping table, under the Subscriber channel container, called NOVLRSERVB-sub-CommandMappingTable that has a mapping of class-name to command.

That is, nrfRequest is mapped to nrf:request. nrfResourceRequest is mapped to nrf:request and User is mapped nrf:identity and so on. (The table has 5 mappings in total, the other two are nrfRole and nrfResourceAssociation to similarly named commands).

[09/03/13 10:06:08.690]:roles ST:
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.0.1.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <nrf:resourceassociation dn="O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20130830154944-7ed335ed4b91425285140a75fbc2c390" xmlns:nrf="urn:dirxml:nrf"/>
  </input>
</nds>

The Roles and Resources Service Driver does its magic in the shim itself, succeeds with the results below:

[09/03/13 10:06:09.823]:roles ST:
<nds dtdversion="3.6.1">
  <source>
    <product instance="Role and Resource Service Driver" version="4.0.0.5730">Novell Role Service Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="0" level="success">Deleted resource association
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20130830154944-7ed335ed4b91425285140a75fbc2c390</status>
  </output>
</nds>
[09/03/13 10:06:09.826]:roles ST:No input transformation policies.
[09/03/13 10:06:09.826]:roles ST:No schema mapping policies.
[09/03/13 10:06:09.826]:roles ST:Resolving association references.
[09/03/13 10:06:09.826]:roles ST:Processing returned document.
[09/03/13 10:06:09.827]:roles ST:Processing operation <status> for .
[09/03/13 10:06:09.827]:roles ST:
DirXML Log Event -------------------
     Driver:   \TEST_IDM\tstidm\services\driverSet\Role and Resource Service Driver
     Channel:  Subscriber
     Status:   Success
     Message:  Deleted resource association
                DN: O=tstidm\OU=services\CN=driverSet\CN=UserApplication\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20130830154944-7ed335ed4b91425285140a75fbc2c390

Nice and simple output. I think I would like to see more output from it, in trace, to get a better feel for what is going on. I should probably try and see how high a trace level I can go to, and see if that generates more useful output.

That nicely wraps up this segment, stay tuned for more examples coming through in the next few articles in this series. If you happen to have examples of your own, please consider posting them!