- Walking through the Blackboard driver – Part 1
- Walking through the Blackboard driver – Part 2
This is part one of a much shorter than usual series of articles (only 3 or 4 of them I promise) on the Blackboard driver which is new in IDM 4 Sp1.
With the release of NetIQ Identity Manager 4 SP1, in addition to the release of the Standard edition license, three new drivers an RSA Driver, a Blackboard driver, and a Google Apps driver.
I discussed some of the new features and bugs fixed in IDM 4.01 in this series of articles: New features in IDM 4 and 4.01
I have been working on a series of articles walking through driver configurations, policy by policy to try and understand what the driver is doing, under the covers.
You can see more of these walk through’s on a Wiki page I maintain to keep them all together:
I have worked through the Google Apps driver in a series of articles, and figured Blackboard seems like a good starting point.
In this article I would like to start on the Subscriber channel in the Event Transformation Policy set.
One of the things the three new drivers have in common is that they are mostly Subscriber channel drivers. That is, they send events into their connected systems but cannot really get events out of them. This is a shame, since bidirectional synchronization is really powerful, but not all connected systems provide an event system, or even a mechanism to poll to build a fake event like system. If that is the case, there is not much that can be done about it, and we had best be satisfied with what we get.
Now the three new drivers are obviously partner contributed, the Google Apps by Consensus Consulting, the RSA Driver by TriVir, and the Blackboard driver by Omnibond. The guys at Omnibond do a great job on drivers as you can see in their current set of drivers they provide. They make the Unix/Linux driver, the Midrange (aka AS400, i5os, iSeries) driver, the Mainframe drivers (Top Secret, ACF2, RACF) in both bidirectional and fanout versions. They also make the Scripting driver.
Blackboard is a course management and teaching system used in many schools, with some common competitors like WebCT.
Coming with IDM 4 SP 1, this driver is delivered as a set of Packages. There are only 4 packages involved, Base, Default Configuration, Group Based Enrollments, and User Entitlements. Interestingly absent is password synchronization, Account Tracking, and some of the other Packages Novell provides for common functionality. I would guess that Password synchronization functionality is not needed as Blackboard probably can do its logins against LDAP, which is often then said to be sufficient to integrate the system. But of course there is more than just logging in that is of interest in a connected system. Groups, Roles, and Permissions if possible to manage centrally, can add a great deal of value to the solution. Specifically when you can tie higher level Role models into lower level entitlements to Groups, Roles, or Permissions.
There is not a lot of configuration information in this driver that might give hints at some of the things it can do or handle. Most of the choices you can control are in the GCV objects. There are some scoping controls in terms of limiting the driver to a single container or all objects in the tree. Some controls on setting the required attributes of an object in Blackboard to be the Source Name of the object. I guess since they are required, and might not be set in eDirectory that setting them to a reasonable value versus waiting for them to be entered into eDirectory can make a fair bit of sense.
There are some default roles and institutional roles that can be set in Blackboard and you get to provide the values you would like to use.
It looks like Group objects are used to represent course enrollments, but are not actually mapped that way in the schema map and filter. Instead there is a rule in the Subscriber Command Transform that converts them. This is an interesting approach and I will enquire to see if there is a reason for doing it this way, I am always curious about the trade offs considered when making decisions like this. It is useful to understand the thinking so you can make a better judgement yourself in the future.
Lets start with the Filter, since this is actually interesting in this driver. Usually the filter is pretty boring, and there is not much to say. However in this driver some interesting things can be seen in the filter.
First up we have three object classes, all Subscriber channel synchronize, publisher channel ignore (this is after all a Subscriber channel only driver). The classes are User, Group, and DirXML-BB-Enrollment.
What is interesting is that the User and Group objects have 50 some odd attributes in the filter, but set to ignore on both channels. I.e. They are there taking up space in the XML but have no affect. Usually this is to make it easier on the driver developer later to enable an attribute if needed.
My guess is that this driver can send a fair bit of data to Blackboard if you want too, but out of the box does not. This sort of makes sense, since you may not have the data of interest populated in your Identity Vault already, or may not want your IDV to be the authoritative source for that data.
But by leaving the attributes in the filter it makes it easier to handle them later. The other possibility is that like the AS400 driver (i5os, iSeries, Midrange, it has lots of names) there are all sorts of DirXML-i5os-* schema extensions available to use, to map pretty much every attribute supported, if you so desired, but out of the box, almost none of them are mapped. My thinking is that the same basic notion is in place here. Personally I think that perhaps they should consider offering two different base configuration Packages. One with just a simple working out of the box model, and a second one, that has all the attributes in use, allowing you to easily see the difference between the two approaches. This is sort of one of Packages key features. If you do not agree with the base configuration, make your own! In this case since there does seem to be such a disparity in terms of how you might configure the driver it makes sense to offer some choices. In the past you would probably have tried to use a GCV to control some behavior so you would have one policy object with a rule for each configuration case, now with Packages this can be a lot easier.
Some comments on the schema naming then. The user related attributes are all named DirXML-BB-p-* with pretty meaningful names after the first part. Things like city, address, phone, etc. Actually synchronizing out of the box are some basic attributes like Given Name, Surname, Internet EMail Address, Login Disabled, and nspmDistributionPassword. That last one is interesting as the manifest of this driver (which indicates some of its features, specifically password synchronization) appears to not mention the ability to synchronize passwords. This does not seem entirely right. I will have to see what I can find out about it. Finally, DirXML-EntitlementRef is set to Subscriber Notify, as we need to know when an Entitlement is changing or available in order to implement Entitlement support.
The Group object has some other interesting attributes, which we will see later on is due to the fact one object class, Group, maps to two classes in Blackboard (Courses and Organizations). So the schema names for the Group related attributes come in two groupings. DirXML-BB-c-* for the course related attributes, like end-date, course-title, enrollment-type and so on. Then there are attributes that begin with DirXML-BB-o-* for the Organization mapping and have some similar attribute names, but different ones as well.
The Member, Owner, and Description attributes are the only ones that synchronize in the filter by default. There is no DirXML-EntitlementRef since even if this driver supported a Group Entitlement (which it does not) it would still need the attribute to be notify on the user, not on the group since the Group entitlement is actually added to the User to entitle access to the remote Group. Not on the Group in the IDV itself.
The final class is DirXML-BB-Enrollment, and this has five custom attributes of its own that are set to synchronize on the Subscriber channel only.
We should see later in the driver how these attributes are used. The DirXML-BB-enr-c-ext-key and the DirXML-BB-enr-p-ext-key are the identifiers that link the User (the -p- attribute) by its Association in this driver, and the Course object (the -c- one) by its Association value in this driver.
The DirXML-BB-enr-row-status is set to ENABLED when there is an enrollment, and the entire object is deleted when it goes away. The DirXML-BB-enr-role value comes from the GCV set for default Roles. I am not sure what the DirXML-BB-enr-datasource is used for.
As you can see this drivers filter is a little more interesting that other drivers usually are.
What is interesting as well is that in the schema map, very little is mapped, and in fact Given Name is mapped to DirXML-BB-p-firstname, Surname is mapped to DirXML-BB-p-lastname, Internet EMail Address is mapped to DirXML-BB-p-email, and the nspmDistributionPassword is mapped to DirXML-BB-p-password. Which explains why it is in the filter, and sort of explains why the standard password Package is not used.
Normally in a driver, we see a modify event for an attribute nspmDistributionPassword if your Identity vault is set to use Universal Password and the password policy syncs that to the Distribution Password.
There are some GCV’s used to control Password Sync behavior, and based on how they are set, they convert the modify of the attribute event into a new event which the shim usually handles as a special case. Here we see that the attribute syncs straight through to the DirXML-BB-p-password attribute. The default rules would work here, if you set it to NOT use Universal Password, Subscriber only, which is actually sufficiently misleading that it is probably not worth adding in. That is, it is better to simply send it in straight through rather than use a seemingly incorrect configuration for the Password Synchronization settings. I am torn as to which I prefer in this case as both approaches have merit.
Modifying the base Novell Package for password synchronization would be ill advised, since then you would lose the benefits of possible updates should bugs be found in it later in the game. Thus I guess I can see why they configured the driver this way.
If you want to read more about the Password Synchronization rules (most of them are visible in the Subscriber and Publisher Command Transform policy sets in most drivers) you can read my articles on the topic here:
What this does mean is that this driver will support Password Tunneling mode, which is kind of a neat use case, where changes in the connected systems flow into the IDV as the Distribution Password (nspmDistributionPassword), but do not actually affect the IDV passwords (The Universal Password, which is actually nspmPassword). But it flows into the IDV as the Distribution Password, syncs out to the other systems as the Distribution Password but does not affect the actual Universal Password in the IDV.
You can read more about the concept of password tunneling in this article:
It is pretty rare that you need to use password tunneling, but when you do it is quite a clever and powerful solution.
That about wraps up this article. Stay tuned for more as I continue walking through the various components of this driver. Next up will be working through the Subscriber channel rules, starting with the Subscriber Event Transformation Policy Set.