Recently Novell shipped Identity Manager 4.0 Advanced Edition. This is a great new release of Novell Identity Manager and has lots of fun new features.
The high level list of new stuff like a small list, but much of the functionality will have really powerful repercussions on how IDM is used in the future.
There are some high level things like two new drivers (well 4 actually, two are needed for the Reporting service) for Sharepoint and Salesforce,com. The Role Mapping Administrator tool is very useful and something that should be really interesting as it develops. The Reporting service will be a great help as well.
Of course there is a new and updated Designer, now at version 4. I started using Designer 4 on a new project I was working on (actually using IDM 3.6.1 since they are not yet licensed for IDM 4) and tried adding a feature that was not supported on a IDM 3.6.1 engine. A pop up box came up (which was a nice warning) with a link to some documentation on new features within IDM 4. You can find the HTML files in your Designer install (assuming you installed it to c:\Program Files\Novell\Designer) at:
What I found quite interesting though was this page:
This listed the main new features added in the different IDM versions, starting with IDM 3.5, through 3.6 and on to 4.0. This I found quite interesting, as I often forget when a feature was added. This is most painful when I have to go back to IDM 3.0 installs and do work. This was so painful I wrote up a set of workarounds for some of the pain points I often encountered working in IDM 3 after using IDM 3.5 and higher in this article:
I thought that the table of changed items was sufficiently interesting that it would be worth an article on the topic and take a trip down memory lane.
IDM 3.5 new features:
- New object types were added:
- ECMAScript Objects
- Mapping Table Resource Objects
- Resource Libraries
- New Policy Linking capabilities where a policy can be in multiple lists
- Many new DirXML Script actions, conditions, tokens, and verbs
- Ability for DirXML Script to nest conditions
- Driver-scoped local variables in DirXML Script that let you refer to variables outside of the policy
IDM 3.6 new features:
- Support for 64-Bit operating systems
- New installation program
- New driver configuration files
- Driver health monitoring
- New ID Provider driver
- Reciprocal Attribute Mapping
- Additional DirXML Script elements
- Nested group support
- User Application
IDM 4 new features:
- Integrated installer
- New Resource Objects
- Global configuration resource objects
- Package prompt resource objects
- DS resource objects
- SharePoint driver
- Salesforce.com driver
- Identity Reporting Module
Lets talk about some of these features. In Part 1 What has changed between Identity Manager versions - Part 1 of this series, I covered IDM 3.5.
In Part 2 What has changed between Identity Manager versions - Part 2 of this series I covered the listed new features of IDM 3.6.
In this article lets start looking at IDM 4 new features. Now IDM 4 is both a doozy of an upgrade, and a boring upgrade. We do not get a bunch of new tokens like we did in 3.5, but we do get a radical change in how driver configurations are managed, and it is a huge change for the better.
The Integrated installer is a nice idea. It is more specifically required for the Roles Based Provisioning Module (RBPM) side of the house, since the basic IDM install for the engine and event side is pretty simple. However as more and more functionality in IDM 4 is based off the Roles model inherent in the RBPM model, you need the RBPM module installed for more functionality to even work. For example, the ability to access the Reporting module is controlled by a Role, managed in the User Application (RBPM version) and enforced or applied by the Roles and Services driver. Also a lot of the new functionality, like the Reporting module, the Roles Mapping Administrator are installed as almost standalone applications, so without the integrated installer effort there would have been a lot more install work needed to be performed just to get up and running.
What it does that is most useful is to separate the installation and configuration pieces into two separate places. This means you can install all the binaries with one install script and properties file, say into a VM base image. Then when you need to use the VM, you can configure it with the second part, by providing a properties file with the information needed.
This feeds into the Cloud ready comments you will hear them talk about in regards to IDM 4. You can read more on my thoughts about the Cloud and what it means for IDM 4, in this article: What does it mean to be in the cloud, when talking about IDM?
Having said that, the separate components are still installable standalone, but you can install them all much easier now.
Packages. Oh what to say about packages. Lets start with I think these are the greatest thing since sliced bread! One of the current weaknesses of Novell's IDM solution has to do with upgrading. Upgrading the binaries (especially under Linux) is a piece of cake. (rpm -U). However, upgrading a configuration is almost impossible. It is probably simpler to rebuild using the new configuration as a fresh driver.
Packages are an attempt to bring some sanity to this problem. This will allow Novell to break up a driver configuration into smaller components, making updates easier and simpler. Then there is versioning, so that you can easily upgrade and downgrade between versions.
The items in the feature list break it out into two parts, installation and management. This is because they did not just provide packages for all the drivers in IDM 4, they also provided a mechanism for consultants and third party developers to easily build their own packages. So if you sell a custom driver (say to Google Apps, since there are 4 or 5 of those out there) then you can distribute your driver configuration as a package now. A package gets bundled up into a JAR file, and a descriptor file, so distributing them is pretty easy. In fact, all you need to do is make them available over HTTP somewhere.
One thing that makes me happy is that as I push for better commentary in each rule, (which is starting to happen finally), it has been hard to convince Novell to spend time on it. However, with packages, each former configuration is now broken down into many parts, some of which are reused. In which case, documenting one package is a much smaller and easier task, than taking on an entire driver configuration file. You can see my attempt to resolve that problem on the Wiki page I maintain with a list of articles related to detailed driver walkthroughs:
I have already written an article on Packages in Designer, and intend to do a couple more since there is so much to cover on this new feature. You can read about it here: A first look at some of Designer 4.0 New Features
Now to enable packages, a number of things had to happen. They needed to be able to break out all the 'things' that come in a driver configuration, and allow multiple instances of each. For example, many drivers include Global Configuration Variables (GCV), but what if one package say the base driver needs three GCV values, and then the password synchronization package needs 6 more GCVs and the Identity Tracking needs 3 more. With the previous monolithic model of GCV values, this would not work.
With IDM 4, there is a new resource object, to store GCV's, and these can be linked to drivers just like you would link an ECMA Script resource object to make the ECMA functions defined in it available to the driver. This does mean that the old approach of reading GCV's from a driver object needs to be changed. Used to be that the DirXML-ConfigValues attribute held the GCV data as an XML document. That meant if you wanted too, you could read back the attribute pretty easily, and look at the XML if you had such a need. Now you would have to read back all DirXML-GlobalConfigDef object, and gather all the available GCV's if you wanted to be complete.
As I mentioned in a previous article in this series, the way they handled Resource objects is clever. There is a single object class, DirXML-Resource, and it has an attribute DirXML-ContentType that is used to define what kind of resource it is. Then there is DirXML-Data to store an arbitrary string data payload. Now in IDM this is almost always some XML document, but in principle it does not have to be. As in the case of an ECMA Script object, where it is just text with the code for the ECMA Script functions. Now as it happens, the new GCV objects are NOT DirXML-Resource objects, rather they use a new object class, DirXML-GlobalConfigDef. I would love to have a discussion about why exactly this decision was made instead of reusing the DirXML-Resource object.
The Designer user interface reads the DirXML-ContentType and presents the right UI for the data stored. I notice it also has the ability to stored a DirXML-NamedPassword attribute, so it looks like you can make a password resource as well.
DS Resource objects, I thought has shown up earlier, which allow you to specify any arbitrary object that can exist in eDirectory, as part of your package or driver configuration. (I could have sworn I saw a IDM 3.6 configuration use this before). This way you could make some groups, or perhaps a custom class object that might be needed. You could use the LDIF object that Designer allows, but that is more of a one time thing, whereas this is the sort of object you would want to persist and update over time.
There are several new drivers that come with IDM 4. The Sharepoint driver is interesting as it is written in .NET and needs a new remote loader type, the .NET Remote Loader. We already have 5 different remote loaders, what's one more (Win 32, standard Java one, simple Java RL, Omnibonds fanout driver style remote loader, and Omnibonds bidirectional driver style remote loader. You can read more about these in this article: The Many Faces of Remote Loaders in IDM). This will allow you to manage one Site per driver in this release. I am not that familiar with Sharepoint so I have not played with this one much.
The Salesforce.com driver is interesting. This is a first release driver, and currently only supports the Subscriber channel. That is, it can push users into Salesforce.com and set passwords in it. Which is useful, but not yet complete. For a client I was at, I have been working on a bidirectional version that works pretty well and you can read about in this series of articles:
There are actually two more drivers that are new in IDM 4, but like the Roles and Services driver they are more for back end processes than front end connectivity to systems.
These two new drivers are used by the Reporting module to get data out of IDM and into the reporting database. When Novell acquired eSecurity for the Sentinel product line, Sentinel was using commercial licensed software for a number of functions. (SoniqMQ as the message bus, Business Objects Enterprise (BOE) for reporting and more). As they tried to make Sentinel more affordable they released Sentinel RD (Rapid Deployment) which uses ActiveMQ and Jasper Reports, open source versions that do much the same thing. These are also the approach used in Sentinel Log Manager. Well the Reporting module uses Jasper as well. This means that any work you do in either space (Sentinel or IDM Reporting) carries over well between them. In fact the SDK to develop to either is basically the same tool (an Eclipse based IDE).
Reporting is going to be a great addition to IDM 4 and will likely be an entire other topic all on its own. The shipping IDM comes with a number of prebuilt reports. My hope is that over time as people get experience with the reporting capabilities we will see people posting reports to Cool Solutions to share around. These reports, like Sentinel Solution packs are easily portable, which is nice.
The one report I am most interesting in seeing, which was not ready when I did some early training on IDM 4, is called the state report. This is the notion of showing you the state of any object at any point in time. This is to answer the question of, did this user change? Without some kind of auditing it is hard to know. With Reporting I am hoping we will get the backup server view, where you can see all revisions of the object available over time.
I do notice one major feature that is missing from the list. The Role Mapping Administrator. This combined with the licensed Aveksa product, Access Governance Suite (AGS) allow you to easily look into your connected systems, read out the Resources, and build Roles for the RBPM module that are composed of many Resources. Right now it is not hard, but not easy. The idea of the RMA tool is to almost be able to give it to the folks on the business end of the stick and tell them, build the Roles you want, the way you want them.
AGS lets you validate that the Roles do not have any Separation of Duties issues, and report on the Roles in the systems. Additionally, when you are started building Roles for your IDM system, you can use AGS to look into your various systems, pull in all the existing entitlement grants, and let it try and calculate typical Roles. In other words, if you have hundreds of users with the same basic set of entitlements that is basically a pre-defined Role, whether you know it or not. Now AGS can help derive these existing unknown Roles for you!
Overall I think IDM 4 brings a lot of interesting new features to the table, and it looks like Novell has planned IDM 4 to be more of a phased roll out as more features are planned, and will be released in updates. I am quite looking forward to using all the new features!
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.