Radovan Semančík's Weblog

Automated User Provisioning using Role-Based Access Control. You know the concept as you sell it to customer: Sooner or later Mr. Customer decides to implement IDM. And now it is your turn to fulfill what you promised. First thing that you realize is that "few key roles" will not be that few. You will need build the "key roles" from sub-roles, many of which are system-dependent. And soon it turns out that the number of roles will exceed the number of employees. Well, you finally find a way how to reduce the number of roles (I will describe this "Role Explosion" problem later), but you have another problem now.

You need to assign the roles to the employees. You think: "Ahhh, now it's going to be easy. I just got the electronic version of that organizational chart, I'll put it somewhere and I'll hack the workflow to look at it while assigning roles." That's exactly how I looked at it. But now the reality:

First fact that you find out is that there is no single organizational structure source. One structure is in the HR system. And that's for accounting and statistics purposes. Then there is an orgstruct in groupware system. That's used by all that little cozy applications like telephone number directory and micro-workflows. And there are another (usually partial or modified) versions of organization structure in different applications, beginning with Active Directory and ending with quite-unimportant-department-application-that-was-not-really-used-in-years.

All of the responsible people would swear to you that all these structures are only replicas of the one primary organizational structure (usually that one in the HR system). "Oh, well, that's fine. I can choose the one that best suits me", you think. And then you choose one and start to use it in your workflows. All works fine on the test data, but it suddenly break up when deployed in the "real" environment. After a while (that looks like weeks to you, with all these managers screaming around) you'll find out that all the organizational structures were not that much same. And according to Murphy's law you've choosen the worst one. But that not really matters, because later you'll find out that there is no consistent source of organizational structure anyway. One version has most of the data that you need but the relations are all broken. The other has the relations fine, but there is no unique key how to merge these two. And after a while you'll find out that the data there are "a bit outdated" anyway ...

The only thing that you can do is to return back to the architecture&design phase and re-desing the modules that deal with organizational structure. Current provisioning systems are great at merging people records, but fail terribly when it comes to merging organizational structure. So we've developed our own tools to do that. We merge the structure to a single "view" in the Directory Server and use that as a database for workflow decisions. And it quite works.

Moral:

1. Never trust anyone telling you that they have single, consistent organizational structure source that you can use.
2. Allways analyse the quality of data, not only their availability.
3. Provisioning system is not the only tool that you'll need. Prepare to develop your own "gadgets". Make a "padding" in the project plan for the unexpected.

More than a year ago a project was started. It took year-and-a-half of pre-sales activities to get it started, but it was finally lauched. It was an Enterprise Identity Management project. Or more specifically it was only first part of larger IDM vision. But what was so unique in this projects that it's worth writing about it?

First of all we used new and exciting technology. The basic component was Waveset Lighthouse, now called Sun Java System Identity Manager. Great user provisioning product. The other components being Sun Java System Directory Server and home-brewed integration tools - all of them heavily customized to met customer's needs.

Then, it was the first complex IDM project in the Central/Eastern Europe. It was quite rapid (less than a year) and it was successful. Something not frequently seen in these longitudes.

And finally, I've personally drafted the first preliminary pre-sales concept, architected the whole solution, technically led the project, took the most difficult technical bits for myself to implement and watched the whole project till the very end. From my egocentric point of view it is The Project to be proud of.

But it is not the success of the project that I want to write about. I think that the problems that we encountered, the little failures and unmet expectations - these are the things worth noting.

In the next few blog posts I want to describe some of the key problems that were not apparent in the early project phases and that struck with hurricane-force in the most incovenient times. These are usually not technological problems, but rather "philosophical" ones, concerning solution desing, customer understanding and things like that. I workd on several other IDM-related activities since then and all these problems are apparent for other customers also. So I decided that it is worth sharing the experience. Maybe it can save you a lot of time.

Stay tuned.