Cybersecurity
DevOps Cloud
IT Operations Cloud
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.
In the fourth article Walking through the SIF driver - Part 4 I worked through the rest of the Input Transform, the Publisher Event Transform, and into the Matching rules.
In the fifth article Walking through the SIF driver - Part 5 I worked through the Creation Policy and Placement Policy Sets.
Now on to the Publisher Command Transformation Policy set. This has eight policy objects, but four of them are the standard password synchronization policies, that you can read about in these articles, that discuss how a <modify-password> event comes from the shim, and depending on how the Password Management GCVs (Global Configuration Variables) are set is transformed or not. Basically a modify of the eDirectory RSA key pairs (old school password) will remain a <modify-password> event, where if set to change the Universal Password, it will be transformed into a <modify> event, for the attribute nspmDistributionPassword.
The policy objects are:
This policy object has three rules:
Like most of the policies in this channel that we have seen some local variables are set up, since they are policy scoped, they get cleared as we move on to the next policy so they need to get reset each time. Driver scoped variables are sometimes helpful for this task, but the problem is that the Subscriber and Publisher channels are independent and run at the same time. Thus it would be possible to get an event in one channel processing at the same time as an event in the other, but if you try to rely on driver scoped variables used in both, then it might get changed midstream as its being used. Now if you limit the variable to be used in one channel only it is less likely to be an issue, but care should still be taken. Nothing like leaving a variable uninitialized for the next event to come through to make for immensely confusing results.
This sets up the attributes: