Enterprise Architects should really pay attention to Identity Management
03 Jan 2006James McGovern asked a lot of quesions few days ago. I think I can answer some.
The question on Message-Oriented Middleware is good but avoided one thing that is rarely discussed in terms of identity and that is workflow. Pretty much every Fortune 1000 enterprise already has some form of workflow engine in their shop which is a major component to identity management on the provisioning side. Why would an enterprise want to bring in yet another workflow engine that is relabeled in another context?
Absolutely none of the enterprises that I worked for had any workflow system usable for identity management. They have only small, inflexible (usually groupware-integrated) workflows. They were not exactly Fortune 1000 (I live in East Europe, you see), but I believe the same situation applies to most medium-sized enterprises.
And even if the enterprise has a good workflow engine, it may not be that easy. The "ideneity management workflow" is quite different form usual "document managemt" workflow. First of all, it works with quite special data units (provisioning requests) and has a lots of error conditions to take care about. In theory you can do that with generic workflow engine, but in practice it will be very difficult and will take a long time. Maybe the option of having two workflow engines integrated using WfMC interfaces is lesser evil than spending two years only on unifying identity management workflows. At least for now.
Another component would be connectors to directory services. Could someone tell me how many I need? One could logically assume one for each type of application / technology but if I go down this path, ain't I really just making a bad situation worse? How about telling me that it may be better for me to not spread provisioning type services all over my enterprise and instead recommend to me that I should consolidate identity stores?
You may be right, but only in ideal environment. In the ideal world, you would store your employee data only in one place and use that in all applications. But, imagine you have your employee data in SAP available only using SAP RPC. You may build SAP RPC to DSML adapter (or virtual directory) to make it "standard". Other applications will use DSML to get the employee data and use it instead of user databases. Great. But now imagine that you need to make "join" over that employee data with data internal to the application. That would be terribly ineffective even in medium-sized enterprises. OK, you can cache the employee data in applications, but that way you cannot use DSML (or LDAP) only. That will not support cache invalidation and will not work in security incidents, etc. And I have not yet mentioned legacy applications that will not adapt to anything. The best you can do is to inject user data to their databases and hope that it will not break the application and/or void the warranty conditions and rise suport cost.
The identity store consolidation may be a topic for future (if ever) when you will have unified and clean (SOA?) architecture. But it is not feasible now. "Single directory paradigm" does not work in the practice. A wild mix of directory integration, provisioning and (possibly) federation is the only hope for next 3-5 years.
If I wanted to consolidate identity stores, wouldn't Active Directory be a great place to do such a thing? What if I could get RACF to trust Active Directory? What if I could make all of my other enterprise applications not understand SPML but instead have them consume XACML from a centralized policy server that binds against Active Directory? Maybe I shouldn't care about SAML at all even though folks like Pat Patterson believe I should.
Maybe. But I believe that using directory/XACML will help only the simplest applications. XACML is quite static, complex and yet not that powerful. You may probably not want a policy language but rather a policy service (or more specifically an authorization service). SAML can supply an interface to such, remember PDP and PEP?
And if you want to forget about SPML, how would you manage stateful services/resources such as home directories on fileservers? I can imagine how to create these, but how to delete them? Using some unreliable and cumbersome cleanup/synchronization script? Old provisioning wisdom says that deprovisioning is as important as provisioning, but its importance is almost always underestimated.
The "Enterprise Identity Management" landscape is still in the heavy mist. There is no complete product or suite that can do everything that is needed. You will have to glue several parts together even if you "acquire" a "solution". It is partialy caused by heterogenity of enterprise IT systems. You cannot expect any product that has to span all the glued systems to be a polished monolith.
To get some insight into the real-world problems of enterprise identity management have a look at Enterpise IDM section of my blog or the Desmond O'Neil's Identity Crisis blog.