I had noticed the Oracle EBS drivers get added to Designer a few patches ago, but never really had much of a chance to look at them. As I have been doing in my driver walkthrough series, I decided to do the Oracle eBuisness HR driver next.

In the first article I made it through the configuration, GCVs, and the started working through the Subscriber channel.

In the second article I finished the Matching policy in the Subscriber channel and got into the Command Transform.

In the third article I finished the Command Transform and started into the Output Transform.

In the fourth article I finished the Output Transform, and started in on the first policy in the Input Transform.

In the fifth article I almost finished the Input Transform.

In this article I will finish the Input Transform and start on the Publisher channel.

There is only one more policy object in the Input Transform:

NOVLORAHENT-itp-EntitlementsImpl

This policy is the counterpart of the Output Transform policy NOVLORAHENT-otp-EntitlementsImpl which intercepted the DCS query, and converted it to the __driver_identification_class__ query, which all shims answer with some version information.

Then this event is stripped and converted to look more like this one:

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product version="4.5.0.0">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input>
    <instance class-name="oracleEBSAccount" src-dn="Oracle EBS Server">
      <attr attr-name="DisplayName">
        <value>Oracle EBS Server</value>
      </attr>
      <attr attr-name="Description">
        <value>Oracle EBS Server</value>
      </attr>
      <attr attr-name="Value">
        <value>Oracle EBS Server</value>
      </attr>
    </instance>
  </input>
</nds>

The most interesting part of how it does it is the last action:

<do-strip-xpath expression=".[count(attr)=0]"/>

What happens earlier is the old stuff is stripped out, but you might have some empty nodes, and this last action strips any node whose count of children is 0.

The rest is all done using the Set XML Attribute, Append XML element, and Append XML Text tokens to build the XML item by item as desired. Honestly, I wonder if this would just be simpler to hard code in the XML and just clone it into the document. Seems like that would take fewer steps.

That is, since this is a pretty common case, would it have been simpler to user a more generic rule to reuse like the following action block:

			<do-set-local-variable name="payload" scope="policy">
				<arg-node-set>
					<token-xml-parse>
						<token-text xml:space="preserve">&lt;instance>
      &lt;attr attr-name="DisplayName">
        &lt;value>Oracle EBS Server&lt;/value>
      &lt;/attr>
      &lt;attr attr-name="Description">
        &lt;value>Oracle EBS Server&lt;/value>
      &lt;/attr>
      &lt;attr attr-name="Value">
        &lt;value>Oracle EBS Server&lt;/value>
      &lt;/attr>
&lt;/instance></token-text>
					</token-xml-parse>
				</arg-node-set>
			</do-set-local-variable>
			<do-clone-xpath dest-expression="." src-expression="$payload/instance/*"/>

That first set local variable, payload, will XML Parse some text that looks like XML, basically the bulk of the document. To store it in a nodeset variable you need to make the stuff being stored nodeset friendly, which XML Parse does. Note how inside the <token-text> node, the XML is already escaped (Which makes posting this on a web page hard, since you have to escape the normal less than signs in HTML to show them, then escape the ampersand signs again so that they show up in the HTML view).

If you wanted to be more clever, you could simply have a GCV with the name of the driver type specified (Oracle EBS Server, perhaps in a GCV named drv.static.drivertype). Then you could be even more clever and just use this as the action instead:

			<do-set-local-variable name="payload" scope="policy">
				<arg-node-set>
					<token-xml-parse>
						<token-text xml:space="preserve">&lt;instance>
      &lt;attr attr-name="DisplayName">
        &lt;value>~drv.static.drivertype~&lt;/value>
      &lt;/attr>
      &lt;attr attr-name="Description">
        &lt;value>~drv.static.drivertype~&lt;/value>
      &lt;/attr>
      &lt;attr attr-name="Value">
        &lt;value>~drv.static.drivertype~&lt;/value>
      &lt;/attr>
&lt;/instance></token-text>
					</token-xml-parse>
				</arg-node-set>
			</do-set-local-variable>
			<do-clone-xpath dest-expression="." src-expression="$payload/instance/*"/>

That is, replace the string instances of the Oracle EBS Server with the GCV reference. Seems a bit simpler, and you could even flag the GCV in its definition node with hide='true' which would mean the GUI would not show it, so people would likely never even know it was there to try and modify it. (I would, since that is the sort of thing I like to look for, but I am a bit odd that way).

This approach could be used in most of the non-responsive drivers that do not have this support built into the shim and need policy to fake it out.

That was the end of the Input Transform, now on the Publisher channel (Since technically the Input Transform is outside the Pub/Sub divide, as is the Output Transform) and the Event Transformation policy set.

Publisher Event Transformation:

There is only one policy object here.

NOVLORAHENT-pub-etp-EntitlementsImpl

There is only one rule here, "Disallow user account delete when using entitlements" and it does what the name says.

If a delete event for an object (really only users in this driver) comes through the Publisher channel from EBS, and the GCV drv.entitlement.Employee is true, then it removes the association from the target user, and vetoes the delete. If Entitlements are controlling the Users in EBS HR, then EBS HR should not be deleting users, but even more so, a delete in EBS HR should not be deleting in the IDV.

However, this means you are out of sync. Your user in the IDV has the UserAccount entitlement probably, which tells IDM that they have an EBS HR account granted. But now that account is gone but the entitlement is still there. Fixing this is a bit of a can of worms, since of course just removing the Entitlement from the user at the same time would not help very much. You could do that by iterating over the DirXML-EntitlementRef on the target user, finding the one whose component='volume' matches this driver (with the UserAccount entitlement name) and then deleting that instance of the attribute value. But that would not really accomplish the goal.

The problem is that the RRSD driver when it sees an event for a User will go out, read all the Role and Resource assignments on a user (I say all because it could be values in the attribute nrfAssignedRoles (direct assignment), nrfMemberOf (statically inherited from a group, or is it nrfGroupRoles), or nrfContainerRoles, and then nrfAssignedResources) and figure out the complete proper end state for the user. It would then make sure it is valid. So it will calculate all the Role assignments, update the attributes to be correct, see all the Resource assignments that implies and fix them up. This means the Entitlement would come back, since the Resource that granted it will still be assigned.

Ok, so figuring out which Resource assigned the Entitlement is not terribly hard (not terribly easy either). Query for all nrfResource objects in the User App drivers AppConfig container, and then look at the nrfEntitlement attribute, to see if the volume component references our entitlement. Then you have identified the Resource.

Ok, so that was not so bad, just do a Remove Resource token call, and clear out that Resource assignment. Hold on there buddy, not so fast. Where did this guy get the Resource assignment from? Now we need to figure out which Role granted the Resource, since if we don't exact same problem will reoccur. RRSD will get some future event on the user, reprocess it, and fix back up the Resource you just removed.

Ok, so now we query for nrfResourceAssociations objects in the AppConfig container. It turns out that a Resource is assigned an Entitlement by the use of the nrfEntitlement attribute. But the Role to Resource mapping is handled in the nrfResouraceAssociations objects. So look for one with an nrfResource value that points at our resource objects DN. Not so terrible. The nrfRole attribute tells us which Role object is granting the Resource now, so we can go call Remove Role for that one, right. (Well technical issue, the query for nrfResourceAssociation will return the nrfRole in backslash format so you would need to query for that specific object so that the responding <instance> document will have the qualified-src-dn to be able to convert it to LDAP format as the Remove Role token requires, but that is a minor quibble).

But hold up there cowpoke, same issue again. What if that Role (granting the Resource, which grants the Entitlement) is actually a Level 10 Permission Role and is linked to a Level 20 IT Role, which is then again linked to a Level 30 Business Role? If you only remove one of the lower level assignments, you get into the same problem. And if you remove the entire Role hierarchy that grants this ultimate Resource, you probably remove a lot of other Roles and Resources that were inherited through it.

Thus this is a painful problem to solve. The current RBPM model does not have an exclusion case. That is, there is no way to assign 'something' to Exclude a Resource. That would actually be nice. Build a role model with 3 levels, inheriting all the way down, but assign an exclusion Role to remove a specific Resource from the set. (I am not aware of a way to do this, if someone is, please let me know).

One way to solve this would be to do what the Access Governance products seem to do and flatten the Roles model so there is only one level. Then it seems like every Entitlement is statically defined to a Resource, which is mapped to a single Role. There is no hierarchy of Roles, in which case you look at it and say why bother with Roles at all then?

But in that model you could support removing the one Role/Resource/Entitlement when the User was deleted. Not sure it is worth it though.

You will see some of this as an issue in the PCRS (Permission Collection and Reconciliation Service) approach. It will try and import a valued entitlement, make a Resource out of it, and assign members of that collected permission (Be it a remote Group or some other construct) to the associated user in the IDV.

I need to review what PCRS is doing in greater detail (On my list of planned articles, next in fact after I finish this series) but it looks like it does two things. First it lets you define a series of Entitlement mapping to Resources from a CSV and if not will try and auto generate them regardless. (Like I said I skimmed it, found a bunch of interesting things I want to look at in more detail, and will get to it soon).

I think you can assign the Resource to a Role in that model, as it collects them, but the problem there becomes that now you have Level 10 Permission Roles directly assigned to objects. It is preferred, if you wish to take advantage of the hierarchy, to grant the Roles at a higher level, and only directly grant Permission roles for exception handling.

That is a step I am still unclear on with PCRS. Should you leave the assignments as is, or should you be using Catalog Admin to merge them into your Role structure and start using them like regular Roles? If you remove direct assignments and instead assign to higher level Roles, will the next collection put them back? Now a duplicate grant is probably fine for granting the permission. But when it is time to remove it, I forget exactly what RRSD will do if you have a Business Role assigned, that has IT and Permission Roles as children that grant this Resource. But you also have a direct Resource grant to the User. What happens when you remove the Business Role? Does the direct Resource assignment remain (well that won't get touched) but does the entitlement ultimately go away? Does the direct Resource Assignment continue to grant it? Ok that might not be so bad. But what about the other way? Take away the direct Resource grant, and leave the high level Role?

My feeling in both cases, the existence of one of the two ways of getting the Resource will mean when RRSD recalculates the final permissions, the Resource will still be granted.

The downside is that if you wanted to rely on your Roles model handling permissions, then direct Resource grants sort of puts a kink in it, and you now need to examine that level more carefully when cleaning up/terminating users.

That about wraps up the Publisher Event Transform, was not that much there, but kind of an interesting discussion I think. Stay tuned for more as I try to wrap this up, by completing the Publisher channel.