Novell Identity Manager has several drivers for connecting to all sorts of other systems, one of which is the SIF driver, written by Concensus Consulting. SIF is the Schools Interoperability Framework, which is meant to manage the student life cycle, in terms of enrollment and courses they take.

If you can connect this to an Identity Management system, then you can easily manage their lifecycle within your Identity system in terms of accounts at your school.

If you can then use a product like Novell File Management Suite, you can manage the lifecycle of their files, moving them from server to server (or NAS to NAS or directory to directory) as they change school years, and provisioning shared storage for every class, and finally archiving or removing them when they graduate.

If you use a product like ZENworks Configuration Management then you can manage their lifecycle in terms of applications and workstations.

Put it all together and it is quite compelling! But to use the latter two tools, you need to get the student information into your systems, which is where the SIF driver comes in.

I started writing about this in the first article in this series Walking through the SIF driver - Part 1 where I worked through the beginnings of the Subscriber channel policies.

Then in the second article Walking through the SIF driver - Part 2, I worked through the rest of the Sub Event, Sub Command, and the beginning of the Output Transform.

In the third article Walking through the SIF driver - Part 3 I worked through the rest of the output transform and once done, moved on into the Input Transform.

Now to finish up the Input transform and get into the Publisher Event Transformation where the really interesting stuff starts to happen!

In the Input Transform we left off in the policy object: input-Data_Transform_Policy where there is one more rule left to discuss.

Validate associations-RefIDs for Object Add Events:

This rule fires on add events where a sifClass attribute is available in the operational document. (Another way of saying If operation attribute is available).

Then since an <add> event has only <add-attr> nodes to consider the XPATH is fairly simple. Unlike <modify> events where there is a <modify-attr> child node, and then possibly one of three (or two of three) child nodes. <add-value>, <remove-value>, and <remove-all-values> in each of those <modify-attr> nodes.

They loop through the XPATH of:
./add-attr/value[@association-ref]

This means in the current event (period) the <add-attr> node whose <value> node has an XML attribute of association-ref. That is the value node might look like:

<value association-ref="SomeGUIDLikeValue">

They can do this since they know the shim they wrote will add the association-ref on any DN syntax flagged attributes.

You know, I wonder what the DirXML-ApplicationSchema looks like on this driver object. The definition of what is a DN syntax attribute in the connected system is stored in the XML in this attribute on the driver object and this would probably be informative to know working through this driver.

You can see a really cool example of leveraging the content in the DirXML-ApplicationSchema attribute in this article my boss wrote, about looking at the document you are about to send to Active Directory and for each attribute, looking it up in the DirXML-ApplicationSchema, and check if multi-valued=true is set. If it isn't then it is a single valued attribute and thus you need to be careful how you send it to Active Directory. Otherwise you could get one of those errors you get when you try to add a second (and maybe a third) value to a single valued attribute in Active Directory.

Generic Single-valued Schema Enforcement

If there is such an attribute value, then a query is done against the destination (eDirectory, the Identity Vault), for the object who has the Association value of the association-ref value. The Query token can query by DN (like O\OU\Users\Jsmith, by a matching pattern (like CN=jsmith, or uid=bsmith) or by the association to this driver that it has. Of course that requires that the object already be associated, but that's ok, so long as you know that is expected.

The Resolve token is basically a special case token that wraps this functionality in a simpler way and returns either a DN or an Association for an object based on the other half of that pairing. (I.e. It can resolve a DN to an Association value, or given an Association value, find the DN of the object bearing it).

Now here is where this gets a bit odd. If there is NOT a src-dn XML attribute (i.e. there is no object found with that association value. What I just discussed that you need to know there is an associated object) then it gets the sifClass name from a mapping table, using the attribute name to figure out what class this is related to, traces a message that it is querying back to SIF for the SIF GUID, and then it does the query back to SIF.

But here is the problem. After it does the query, it does nothing with it. So why even bother? The variable it stores the query in is going to be overwritten if there is another attribute in a microsecond anyway, and they do not add an operational property or a driver scoped variable to try and carry the event over to the next set of rules.

It just queries and then does nothing with it. This leaves me wondering, what is the point. This is one of those times were a comment in the Comment field by the driver author to clarify this would be really helpful. I have teased the guys at Consensus about this regularly, and they have learned to just ignore me, but I would like to see more commentary in the drivers where possible. Heck to the point where articles like this are not needed anymore. Alas I can dream.

I will ask them guys at Consensus and update the document when I find out what is going on here. But for now it is just odd.

That concludes the Input Transform. Next up is the Schema Map Policy set and this has some interesting implications as well.

Schema Map:

This driver only comes with a single policy for the Schema Map. This is interesting as with the release of IDM 4, and support for Reporting there is now a Package that implements the Reporting stuff, and it includes the same rule, linked into the Schema Map before and after the main Schema Mapping policy object. This is used to allow a query into the remote system to be handled slightly differently in terms of mapping, if it is coming via the Reporting functionality. Since Novell has not clearly documented what is involved in adding Reporting to other drivers, I have taken a swing at it, and you can read about it in this series:

• Adding IDM4 Reporting support to pre-IDM4 drivers - Part 1

• Adding IDM4 Reporting support to pre-IDM4 drivers - Part 2

For more information about how the drivers are configured to support Reporting there is much more detail in this series of articles about the two drivers, Managed System Gateway and Data Collection Service drivers:

Managed System Gateway:

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 1

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 2

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 3

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 4

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 5

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 6

Data Collection Service:

• Data Collection Service Driver Walkthrough - Part 1

• Data Collection Service Driver Walkthrough - Part 2

• Data Collection Service Driver Walkthrough - Part 3

• Data Collection Service Driver Walkthrough - Part 4

• Data Collection Service Driver Walkthrough - Part 5

• Data Collection Service Driver Walkthrough - Part 6

• Data Collection Service Driver Walkthrough - Part 7

• Data Collection Service Driver Walkthrough - Part 8

Anyway in this driver, the schema map is slightly different than in most. There are no class mappings defined. That is, there is no say, eDirectory class User mapped to SIF class staffPersonal. This is shown in the interface as Non Class Specific Mapping. In the XML this is sort of interesting when you consider how Designer renders it. You might expect there would be a node for a class, containing all the attributes mapped that belong to it as children perhaps.

But in fact, the XML for each attribute looks like:

	<attr-name>
		<nds-name>ccSIF-Capacity</nds-name>
		<app-name>Capacity</app-name>
	</attr-name>
	

When you add a class mapping you get something like this, which is as you would expect.

	<class-name>
		<nds-name>User</nds-name>
		<app-name>ccSIF-User</app-name>
	</class-name>
	

But the attributes that belong to the class are not children, they are actually siblings, and they have an XML attribute class-name="eDirClassName". Thus you have a single level, with all the class and attribute mappings as siblings. I do wonder why they did that, when it seems like a much simpler structure to have just made attr-name a child of class-name. I wonder if this use case is why? That is, if attr-name needed to be a child node to a class-name node, then how would you do a non class specific mapping? I imagine you could use a dummy class node, or some special value, so I guess this is the approach they decided to take. I would love to hear about the discussion behind this decision. I find it really interesting to find out the thinking behind decisions made. I usually learn something out of it.

Thus the Non Class Specific Mapping case is the absence of the class-name attribute. So in fact, every time you switch to the Mapping Editor view from the XML Source, it has to reparse and render the mappings. (Its neat to see how much work goes on under the covers to display what looks like a fairly simple thing).

Anyway, because many classes in eDirectory are basically mapped to one class in SIF, but with a sifClass attribute to distinguish them apart the schema map, based on object class will not work very well for this driver.

Thus all the attributes in the map are 'classless'. (Better than low class, right?).

Now I discussed that the sifClass attribute is used on the Publisher channel to identify what class in eDirectory we are talking about and set the operational class. (Remember there is a token to do this, Set Operation. You could of course do it in via a Set XML Attribute of with a target XML of . (period, the current operation), class-name as the XML Attribute name, and whatever the class should be).

What about the Subscriber channel? Well there is a mapping table at the root of the driver called sifObjectClassReference that has another approach to the mapping table. There are three columns, sifClass, sifAttribute, and sifClassReferenced and this is used to figure out what sifClass value to set in the document as it goes to the SIF driver. Very nice approach. We will find some rules that use this later.

That's it for the Schema Map, onwards we march! Interestingly enough there are no policies in the Publisher Event Transform, so off to the Matching Policy Set we go.

Matching Policy Set:

There are two Policy objects:

1. pub_Matching_SIF_Upgrade

• pub_Matching

1. pub_Matching_SIF_Upgrade

This has a single rule:

Match all User objects based on StudentInformation System ID

This matches User objects based on the DirXML-sifSISID using the operational attribute ccSIF-SISID. This I imagine is why the Policy object is named pub_Matching_SIF_Upgrade as older versions of the driver no doubt used DirXML-sifSISID as the attribute holding it, and now that Consensus Consulting (the cc of their attribute suffixes) is running the driver they have changed over.

Thus this will find matching objects and at the very least associate it properly if they were using the previous driver. I think I will keep an eye open for any other such Upgrade processes they have put in place. I am alas not very familiar with the previous SIF driver to know what else needs to be changed to support an upgrade. But nice to see them making the effort! Usually there is no good way to get from one version of a driver to another. Packages will help us in the future, but would not really help in this case, I would think.

2. pub_Matching

This is the main matching policy object that has two Rules:

1. Match staff on description for SISID

• Match all User objects based on StudentInformation System ID

1. Match staff on description for SISID

For User objects, the class of which is mapped by the Input transform, based on the shims class-name XML attribute set as sifClass, and then looking into the Structured GCV to figure out what eDirectory class it should be mapped to, since otherwise they would all come in one basic class out of SIF.

But here we have a User, who can be a couple of different things, so the ones whose ccSIF-class is staffPersonal, we search for the Description attribute which matches the ccSIF-SISID. Now I wonder why they are using Description this way. I will have to keep an eye on this, since Description is a lousy place to store something like this (unless they really want it to be visible on the standard editing tools top pages (Console One, iManager, User Application or whatever). Usually Description is already in use for other things, so this might be a bit of an issue for some sites.

2. Match all User objects based on StudentInformation System ID

For all other users, so I would guess students and non-staff in this case, look at the DirXML-sifSISID based on the data in the ccSIF-SISID for the matching rule.

That looks like it for the Matching rule. Which basically says use the student ID in SIF as the matching attribute. Just like you would probably use something like an employee ID or workforceID in a typical HR system. (Amusingly in SAP HR, that would be PERNUM, except that there are a series of valid cases where the PERNUM changes! In which case there is an even more canonical employee number available. Like everything else in your SAP HR system its just there to make your head spin.)