With the release of the Compliance Management Platform (CMP), Novell started onto a slightly different path than in the past, with Identity Manager, and its associated products.
With the CMP Novell is trying to make the entire kit and kaboodle easier to implement. As a consequence, several products are bundled together in the CMP, and connectors between them are added.
The CMP consists of Novell Identity Manager which is the core of the product, with the Roles Based Provisioning Module (RBPM) included. This provides the links between different systems, and the Provisioning module provides the rights management model and work flows to request more rights and much much more.
Novell Access Manager is included for handling web access to resources based on data in the identity system provided by IDM. This allows for web based single sign on, and other advanced tasks. There is an SSL VPN available for general remote client access, web accelerators, the ability to protect resources behind an SSL connection (SSLize a web resource) and Federation tasks with other identity systems.
Novell Sentinel is included for auditing all of this, and collecting events and correlating them for security breaches.
So far there is little new, other than bundling them all together. With the CMP there is an interesting driver added, called the Identity Audit driver, which tracks accounts in the various Identity system and sends it on to Sentinel, such that Sentinel can look to correlate events based on IP addresses but also based on Identity. For example, an attack on multiple machines from different IP's but with the same user name used in the attach is likely related. Additionally, if the user account needs to be disabled due to some detected issue, it can flow to all known identities in the entire system.
Additionally, when looking at an event in Sentinel, if there is an identity involved, you can see all the users identity info, and which other systems they may exist while looking at the event itself. This is pretty neat, and can be quite powerful in terms of moving your view of security from being machine or server or host based to being more holistic.
On top of the CMP, Novell has released the CMP Extension for SAP which adds a couple of new SAP drivers, better Sentinel connectivity, and updates to older drivers.
Prior to the CMP Extension for SAP (CEFP? Goodness that is a mouthful) there were really only two SAP drivers. SAP HR, which connected the SAP HR module, that as the name suggests manages HR information for the enterprise, to eDirectory to create users in eDirectory, as they are hired, and to modify or terminate their access as they proceed with the company.
This is one of those split personality drivers where the Subscriber channel uses BAPI (SAP's programming API), and the Publisher channel uses iDOCS for communication.
I have some articles on the topics that might be helpful in understanding the SAP HR driver better here:
The second driver is known as SAP UM (User Management), and is used in a very different way. Each SAP module (of which there are dozens or more) has its own user database, password store, and authorization store (based on Roles).
Thus each SAP module you wish to manage via IDM, would need an instance of SAP UM in the previous build. The good news is that SAP has a module to handle this process as well, known as CUA (Central User Administration) but while it can push accounts to other SAP modules, it cannot manage passwords. Thus a single SAP UM driver to the CUA module could be used to get users into the various SAP modules, and then a second driver per module to synchronize just passwords.
This driver uses BAPI in both channels, and only can send passwords into SAP on the Subscriber channel.
With Identity Manager 3.6.1 they both appear to have been updated to use the latest SAP JConnect (JCO) libraries, using V3 instead of V2 now. This is the library that provides the BAPI access.
This introduces some confusion, since there are now 2 versions of the two existing drivers (4 possible versions now). The way you choose between with version to use is by selecting the correct Java class name. The names are very similar, and while the docs do note this, it is somewhat buried and not trivial to find. (But in Novell's defense, it is there if you look!)
Lothar Haeger ( http://www.novell.com/communities/user/2097 ) kindly put the list of the driver classes used into a forum message, so I assumed it would be ok to reuse his list here:
com.novell.nds.dirxml.driver.sapumshim.SAPDriverShim -> SAP User (JCo2)
com.novell.nds.dirxml.driver.sapusershim.SAPDriverShim -> SAP User (JCo3)
com.novell.nds.dirxml.driver.SAPShim.SAPDriverShim -> SAP HR (JCo2)
com.novell.nds.dirxml.driver.SAPHRShim.SAPDriverShim -> SAP HR (JCo3)
com.novell.nds.dirxml.driver.sap.portal.SAPPortalShim -> SAP Portal
com.novell.nds.dirxml.driver.sap.grcac.SAPGRCACShim -> SAP GRC Access Control
com.novell.nds.dirxml.driver.sap.bl.SAPBLShim -> SAP Business Logic
Of course each of these classes is usually housed in a different JAR file, but that is usually the least of our worries, as the engine install usually installs all driver shims for us.
You can see that the difference between the JCo2 and JCo3 for SAP HR is SAPShim vs SAPHRShim and sapumshim vs sapusershim and why this would be confusing.
Additionally, the SAP UM driver has been significantly updated, with support for a fan out mode, similar in concept to the AS400, Linux/Unix, Mainframe fan out drivers, where a single driver instance manages multiple connections. That is not to say the internals are the same, but rather the high level concept is similar.
It looks like you can run one driver instance for all your SAP modules, and handle it more simply, than the previous models described.
Definitely worth looking at the newest version!
You can also see from that list that there are three more drivers now available! The SAP Portal, SAP GRC Access Control, and SAP Business Logic.
SAP Portal is actually a SOAP shim, wrapped with some hidden XSLT, that converts XDS to SPML. This is also known as the Netweaver portal. To make it worse, the portal can use an existing UM's ABAP instance for its users, LDAP, or its own UME instance (which this driver talks too).
SAP GRC Access Control is meant to integrate parts of the SAP GRC (Governance, Risk, and Compliance) Access Control system for validating Roles and permissions with the IDM Roles Based Access Control provisioning module. The idea being if IDM's RBPM (Roles Based Provisioning Module) is provisioning roles it ought to validate that the role being added/requested is allowed by GRC before allowing it to be added.
This driver is another of the split personality drivers, where the subscriber channel sends events to GRC via some protocol (not named in the docs, and no reference to BAPI and JConnect libraries, so I assume not BAPI/JCO). but the Publisher channel works by receiving SPML requests from the SAP GRC system. SPML is a form of SOAP (Simple Object Access Protocol) and I imagine they leveraged the work on the SOAP driver in this one.
Now this driver has an additional twist, in that SAP as a system, supports events in the future. So does a system like PeopleSoft, and in each case, this has to be handled somehow. In the case of SAP HR it is pretty easy to understand. A person is hired at a specific date, thus there is a start date for the HR record. However there are additional parts to the user record that may not take affect until later, perhaps actually becoming an active employee as of a certain start date. Then actions need to have start and end dates. For example a position date means the previous position change needs to be end dated and the new position gets the start date with eternity (seriously! They use Dec 31 of the year 9999 to indicate eternity!)
Well in the case of SAP GRC, you might have need to grant access at a future date. Or perhaps delimit the access as between two dates. You can imagine this is similar to how eDirectory and Active Directory have expiration dates on accounts, just it is more granular in SAP, and you can expire access rights, at different times.
There are several different ways to handle this need to time delay events, and the SAP HR driver gives you two options. First send all events, regardless of date, and it becomes the job of the implementer to deal with future dated events in policy, or second, let the shim handle future dated events, by storing them in iDOCs renamed to .futr extensions that get processed at that future date.
There are pros and cons to both approaches. The SAP GRC driver takes mostly the first approach, of playing all transactions as they happen, then in policy delaying them through the use of Work Orders, which the final driver, the SAP Business Logic driver is setup to process.
The SAP Business Logic driver is actually one driver doing two almost completely unrelated tasks. The first is acting as a Work Order driver, to process Work Orders as they are created (if they are due) and when they come due, and creating Work Order To Do objects, which the SAP GRC driver will process. This acts as a method of scheduling events into the future.
The second task is managing the relationship between objects in SAP HR. SAP has a module called OM (Organization Management) that has a very complex and powerful method for defining Positions, Jobs, Organizations and managing users in all those roles.
The SAP HR driver exposes some of this functionality but basically out of the box (as of the 3.5 driver configuration. I have not tested with the 3.6.1 configuration, but it is on my list of things to do) it really seems to only handle one of the simpler cases of organizational structure. You can read much more on this topic in the article for more of the gory details:
You can see from the name of that article that it is called Part 1, but I never really got around to writing future parts, because it turns out to be really complex, and was taking a lot of work. My hope is that this new driver obsoletes much of that discussion and I think I will focus on understanding this new driver to better understand what it can do before finishing that series.
This driver looks very interesting and will take me quite some time to suss out all the neat things that it does. I am working on an article to try and figure it all out, and describe it.
I am hoping I can convince others to try and write descriptive articles of this nature, to try and get a big picture view of how the drivers and components interact, as well as how the drivers themselves work internally via Policy and DirXML Script.
I am trying to collect these sort of articles, in a Wiki, and would love to see others contribute anything they have already written so that it is easy to find in one place and to write new content as well!
The Wiki is at:
http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection
and anyone with a Novell eLogin account can edit it, but please feel free to contribute. Especially if you have stuff already written that I have not included and I am not aware of!
I think we really are missing a resource for understanding both the high level fit of the pieces and then the low level workings that get us there. This is my attempt to rectify that problem.
I am hoping people will be willing to contribute an article or two on a driver they know well. Whether it be the entire driver, just a channel (Sub or Pub) or even just a policy set, like the Command Transform. All is welcome and helpful!
Support
Documentation
Learning Services
Partner Programs