Identity Matters

Hi! It's Felix again, and today I am going to write something about provisioning because it's a hot buzzword now. I first heard about it when I was working for several large telcos. Provisioning there meant to manage a subscriber's data (which is effectively the identity, together with many service attributes). You had to manage individual accounts on the voicemail system, the GSM home location registry, the customer care system, multiple service databases, and so on. That was quite a large process. Sometimes you had up to 20 (!!!) databases and LDAP directories to write or read to.

But then the word "provisioning" started popping up in the enterprise world as well. The same logic still applied, but usually the number of databases and the complexity was much below that of a GSM wireless operator. The promise of automated provisioning was that you could add a user, and then local accounts were created wherever needed. In addition to that, a new email address was added, and possibly an entry in the security access database for physical access. Many organizations found it convenient to trigger the initial adding of a new user from the HR system, which made sense. Other organizations had the security departments manage the master entries. That worked for them, too.

When I mention provisioning, I have to mention de-provisioning as well! De-provisioning is to delete accounts, and make sure they are deleted everywhere. After all, an organization would not want to give a disgruntled ex-employee any system access, or an email address at the organization anymore. I remember a very interesting article that Dave Kearns from Network World wrote in his Directory and Identity Management newsletter sometime in 2002. That's quite a while back, and Network World doesn't archive their newsletters that long. When I asked Dave to send me a copy of that article, he promptly did so - and told me that the part is actually from the book "The Perils of Provisioning" that Business Layers put out a few years ago as a marketing tool. So here goes:

"An executive in our company moved into a new house and had a telephone line installed that was connected directly to the company's internal switchboard. After some time, the executive left the company. Needless to say, the phone line was never disconnected. In the meantime, the house has changed hands several times. The real kicker was that the last time the house was put up for sale, it was marketed as having "free long distance" as one of its amenities."

Let's just step back a little bit and look at provisioning not as some pieces of software that synchronize other systems. Instead, let's think about provisioning and de-provisioning as a business process - every organization has one, even if it's not written on paper. If, when you first start a new job, you must spend a week going from one department to another shepherding the provisioning process through yourself, you can just imagine how much money would be lost through such inefficiency. Therefore, provisioning projects are all about transferring this process to automated software that does all the copying and deleting of data from one system to the other.

In the provisioning world, standards such as SPML (Service Provisioning Markup Language) have become quite popular, and that's understandable. SPML is a standardized XML-based protocol that lets systems communicate in a controlled way to add, modify, delete and query identity information. Standardized in this case means that you should (in theory) be able to connect different systems that all talk SPML. In practice, it's not that easy - but it can still be done in a few ways. SPML makes heavy use of DSML, another protocol based on XML that, in turn, borrows quite a bit from the LDAP protocol used to access directory servers (often called LDAP directories or LDAP servers). This means that SPML and DSML can be (and usually are) converted into LDAP requests that are then used to interface LDAP directories – unless, of course, the LDAP directory also talks DSML in a very efficient way. Enough about protocols - sorry if it made your head spin! I'll take a more detailed look at the protocols another time.

Usually, provisioning products talk to other systems in two ways:

* Connectors - when the provisioning systems talk to a remote system through a defined protocol.
* Agents - where special pieces of the provisioning system need to run on the target system to kick off required changes.

There is another case when provisioning systems can talk to other provisioning systems as well, but let's keep that out of scope so things don't get too complicated for now.

If you have the choice of whether to use connectors or agents, think first about security. When you use connectors, you are keeping the provisioning system at an arms length (speaking from the perspective of the particular user database instance). Instead, when you use agents, you will have to install another piece of software from the provisioning system on your user database instance, and give it full administrative rights there. The latter could be a political problem when different groups are involved, or it could be considered a security exposure if no internal security certification of the agent has yet been done by the organization. Connectors, however, talk to another system through a supported protocol that is being managed on the remote side entirely by the remote application. And - surprise! ... SPML pops up quite often in these scenarios.

Provisioning applications don't just serve the purpose of automating the synchronization of identity data. They should also be able to do some other important tasks, such as logging and auditing. In many countries, special legislation mandates that access and modification of specific financial (and other) data is fully logged and that people are held accountable. One that comes to mind is the Sarbanes-Oxley Act in the US. Provisioning software can assist in compliance by logging all changes to users and their profiles. In some cases it can also help to easily analyze what access a specific user had to particular data at any point in time.

So, computerized provisioning sounds like a hot technology. But it is not without problems and issues. One fundamental problem with a provisioning solution is copying the data itself all over the enterprise. Do you have experience with copying data from one to multiple servers, and changing the data, and making different requests every time? Well, I have and, let me tell you, in many different ways it can turn out to be a can of worms just making sure that every system is updated correctly, that no problems arise, and that undo operations will assure every change is perfectly rolled back. Also, there's a time lag between applying changes in different systems, and all kinds of errors can happen because of that. This all results in massive deployment projects, and lots of time spent making sure that everything runs smoothly. And, every time you upgrade one of the many systems that you're synchronizing to, be prepared for some more hard work to test that the synchronization operates correctly before you actually apply the upgrade. Business rules change all the time, and if the provisioning software is not well thought through, then reconfiguration is like a never-ending nightmare.

When we started Symlabs in 2001, provisioning was one of the things that we had already thought about. At that time, provisioning systems were not yet available, and we didn't focus on a "pure" provisioning system. Instead, we wanted to solve the problems of synchronization and copying data in a more generic way. Our flagship product, Symlabs Virtual Directory Server, was conceived as a virtual directory that could easily be extended to work as a connector or as an agent. It supports multiple protocols (including several based on SOAP and XML) to inter-operate in many environments. When deploying a provisioning solution, the Virtual Directory Server works like magical glue, and some of our customers are using it to simplify and accelerate their provisioning solutions - with outstanding results.