I work as a consultant and see a lot of different clients. It is amazing how much you learn about something, even though you thought you knew a lot, when you use it every day.

I like to think this is some of what makes Novell Identity Manager such a fun product to work with. There is so much too it, you are always learning something. To help others out, and honestly to help me remember stuff I have learned, I have been submitting things I have learned to Novell Cool Solutions.

I have something like 250 articles or so published by this point, so I am not kidding when I say there is a lot to learn.

You can see my personal collection of articles, sorted by topic, at this Wiki page I maintain:
http://wiki.novell.com/index.php/Geoffrey_Carman's_personal_collection

There is a lot of great content on Novell Cool Solutions, as many people from all walks of life write articles, and I usually find something interesting to read there on a regular basis. Some of the developers have been contributing lately which leads to quite interesting articles.

On top of that we have the Novell Support Forums at http://forums.novell.com/ (or via NNTP for the real news group reading experience at forums.novell.com in your favorite Newsreader, like Thunderbird, GroupWise, or even tin! But not nn. Nn was a lousy news reader!) There are a couple of great forums there specific to Novell Identity Manager that are quite well trafficked.

Identity Manager has grown over the years, from just synchronizing accounts between connected systems, to include many more functions. Things like Workflow and Provisioning requests, Roles management, Web Single Sign On, and Desktop Single Sign On.

Novell has great products in all these spaces, and they are all useful to make life easier for the end user.

There are several problems in the space. First off, we have many systems that need user credentials. So there is an issue with too many accounts and passwords to remember, but potentially worse than that is the usual issue of when someone is let go for whatever reason, how certain are you that all the various accounts got shut down. That last one is usually a big deal. Nothing like a company going through an audit and finding out they have dead users who still have accounts, and worse of all, they have been showing activity.

Would you like to be the person who has to deal with that audit report?

But looking at it the other way, new users face as much pain as they start at a new company and try to get all the various accounts that they need. There is a real benefit to automating as many of the accounts as possible.

Regardless of how many different accounts you automate, there are some things you just cannot automate, not for technical reasons, but rather for audit compliance reasons. For certain levels of access, say in the billing or finance systems, someone (a real human being) has to put their name on the approval.

This is where Workflows and Provisioning requests come in. This is a really cool idea, that seems like a step backwards, since it is shoving people back into a process that we just spent all this time automating, and yet it has value. This way, you get a logged event, for each decision made. When something happens down the road, there is someone (a human, rather than a process or policy or rule) that made the decision.

This is also a nice way to replace the Manual Task driver. The Manual Task driver was a way to start a non-automated task, send a request to a human, let them do it in the real world, and then when done, report its completion, and return needed information. Like setting up a cell phone with the phone company, or maybe assigning an office (you should be so lucky!) or a cubicle (much more likely!).

Now that you have this interface you can also start doing much much more. Things like Roles, and making sure they do not conflict and convey rights that are in conflict. (The old SOD, Separation of Duties issue).

Now that handles the back end services, which is really important and really useful. However, to the client there is still a different problem. With this approach, the user still has to log in multiple times to multiple services.

To handle this Novell has two products to use, depending on your needs. The first is Novell Access Manager that will let you handle Web based applications with this issue. Basically you use Access Manager to protect web pages all over your enterprise and for each application that requires authentication, you use the already logged in user credentials to single sign on enable your web applications.

Novell Access Manager is a very big product, that can do simple things, or super complex things. It can be as simple as protecting one web page, to managing your entire enterprises web presence. Where some of the complexity comes in, is in how the individual web applications get handled. Some will need form fills, some just need a cookie set, others will need a J2EE agent involved, and yet others will do SAML assertions. Each of these, and even more options are supported in Access Manager. On top of that, you can throw in two factor authentications through the available login methods. Things like an RSA token or an X.509 PKI certificate, for each login, even for applications that have no way of requiring (nor of managing the extra factors) this extra factor.

Thus you can protect your enterprise, provide Single Sign On for your web apps, and add an extra level of security to all the applications in one fell swoop. Pretty darn cool!

However Novell Access Manager does not do much for non web based applications. (Well there are things and tricks you can do, but the basic design is for a web application). What if you have a bunch of legacy thick client applications that run on the local desktop? Well that is where the Novell Secure Login application comes in.

In this case, you install Secure Login on the local workstations, and when the user launches an application that is being managed by Secure Login, it sees the login box, pumps in the credentials, hits the Ok, Login, Next or whatever button, and the user is logged in.

There are two unique features to Secure Login that make it very powerful. The first is that the policy for what can be Single Sign On enabled, can be stored locally (standalone) or in the directory. With this, you get the ability to apply an enterprise wide policy of what and what NOT is allowed to be enabled. Of course, assignments are inherited, and you can manage by exception, which means you can assign one policy for everybody at the highest level of the tree, and then pick a group, an Organizational Unit, or just a single user to apply an exception (more or less capabilities). This really helps make it enterprise ready and distinguishes it from single user versions of this type of application.

The other feature that is great, is that there are prebuilt configurations for all sorts of well known applications, and for those that are not, the default functionality handles most of the applications you will run into. But if you run into subtle problems, then as soon as you get it part of the way, there is a mode that shows you the script being used at the back end by Secure Login, and you can use the scripting language to try and work around the specific issue.

You could write the whole thing from scratch by hand if you wanted, but why bother? Secure Login does a great job of recognizing what it can, and then you have an almost fully fleshed out example to work from, and modify to fix the issues that have come up.

This way you get the best of both worlds. A very powerful automated Single Sign On tool, and the ability to customize it as needed, with a very powerful language to handle odd cases. Then once you have it working on your development workstation, export the policy to a file you can store (and edit for extra tweaking) and then import into your tree to apply to users as needed.

With this suite of tools in hand, you have a great set of products ready to solve pretty much any problem you have run into.

We have a client that had three separate eDirectory trees. A NetWare file and print tree, using a big NetWare 6 node cluster for file and print services. An Identity Vault we built for them, and yet another tree for VPN authorizations.

Then of course they had an Active Directory tree they needed for workstation logins. On top of that they had an enterprise application running on Solaris servers which were using NIS to synchronize users across dozens of Solaris servers.

On top of that they decided they wanted to use their helpdesk application as the authoritative source of user information for this system. So we were not connecting a well known Human Resources package like PeopleSoft or SAP HR, but rather a helpdesk for which there were no out of the box connectors.

Finally they had a retail application that was running on a mainframe, hosted somewhere else in the country, and was using a 3270 terminal session to connect.

Now it turns out, since they ran the application on Solaris thin terminals in some places, on Windows machines others, it did not make a lot of sense to focus on single sign on for the applications.

In the end, we had close to 30 Identity Manager drivers installed, in order to handle all the various functionality they wanted.

We had a lot of fun on this project as we did a ton of really cool customizations, that are really hard to explain. For example we used the Work Order driver in ways it was never intended to be used. The helpdesk system used Work Orders to assign work, and we synchronized those objects into the Identity Vault, and then using the Work Order driver, processed all the ones that we knew how to handle.

We used the User Applications to make this amazing Provisioning Request that looked at a users current status in 9 different systems, and when they used it, showed the current state of the user. Thus for accounts they already had they had options to change or remove. For accounts they did not yet have, they could ask for the accounts, but could not yet modify them.

One of the systems, the mainframe hosted application had numerous options and it all depended on who your boss was, so we used the manager attribute to automate this.

Once they ran through the workflow in User Application, we generated work orders in the helpdesk system, which then went through the existing approvals process. One a work order was approved, it came back to the Identity Vault to be processed, and for the account to be provisioned, changed, or removed.

This was amazing, as it allowed the existing, highly customized system, that all the staff understood how to use to stay in place, but the actual provisioning of accounts got automated.

Thus with no change to the users in the approval chain, we were able to make the process faster and easier. The end user benefited because we were able to synchronize passwords across a very diverse set of operating systems and applications. One password change in all the connected systems was sufficient to set it in all the other systems.

Thus a user who spent all day in Solaris, but once in a while needed access to the retail system or the VPN did not need to remember the passwords, since the changes he made in his most common system would flow to all the others.

Everybody won on this one, and we got to do a really fun and entertaining project!

We did lots more from an audit compliance perspective but that is a whole other long discussion! Maybe another day!

The lesson to take away from this is that the suite of Novell products can do an amazing set of tasks, and they are sufficiently extensible to be able to do almost anything your imagination can come up with!

I'll bet if we showed some of what we did to the designers of the software they would be surprised with our approaches. Which is always a fun way to work.