Radovan Semančík's Weblog

James 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.

The beginning of a new year is usually a time for planning and predictions. I allowed myself a little fun to make these predictions (and hopes) about the "identity" techologies.

1: "Identity" becomes mega-buzzword

Every other company will be "identity-focused". More and more products will be "identity-enabled". You will hear more about "identity" in mainstream media. And most of the people (include those in "identity-focused" companies working on "identity-enabled" products) will know absolutely nothing about what this "identity" is all about. The "identity industry" will be hyped. The stock prices will rise too high to be realistic. Many startups and aquisitions. Some really valuable, most of them average, and some just empty shells with good marketing. As usual.

2: Many "identity" mistakes happen, but it will take a while for them to be seen.

It will become apparent, that "user-centric" identity is not that easy. Not many of the "identity folk" will ever admit it, but they will know, sooner or later. The naive global (URL-based) "identity" systems will proliferate for a while, but (hopefuly) not for long. Most of the current "user-centric identity" systems will need to be redesigned, limited to specific purpose or will just die. Maybe not in 2006, but they may eventually face the fate of X.509. We need to see at least one more generation of "identity" system to get something really usable. Similar situation will be seen in the real world. Many "national ID" and "national database" system will be proposed only to learn that the technology or the approach is not yet good enough. If you ask me who will "win" on the Internet, I think that it would be something based on WS-Trust. Or maybe something similar to WS-Trust that can be used both over SOAP and REST. But that will not be apparent in 2006. And I think (a hope again) that the "claims" will be SAML-based.

3: More client-side identity implementations will be seen.

As of today, we have almost exclusively seen only pure-web server-side "identity" solutions. As the technology starts to mature, we may see more of a client-side support for "identity". Microsoft "identity selector" (InfoCards), and Liberty-Enabled Client Profile being the first signs, but I believe there will be more activity. Maybe Mozilla community will be drawn to "identity". Or maybe we will see first "identity selector" for Linux?

4: Enterprise Identity Management will spread through Europe.

This one is more a hope than a prediction. European companies are quite late adopters of Enterprise Identity Management technologies. I think that it will change, but the change will be quite slow (especially here in Central/Eastern Europe). There will be a bit more "identity" projects in 2006. But the hype wave will come with full strength in the following years, powered by regulations such as Sarbanes-Oxley or EU auditing rules.

5: Spam, phishing and pharming will get even wilder.

This is a safe bet. Nothing can be done to help in this area given current technology and only one year of progress. Spam will continue unhindered, heuristic methods being the most effective. The community will start to design the replacement for SMTP, that will be based on identity and social networking. It will not be seen as SMTP replacement at first, but will evolve to that. The phraud will move on beyond its current primitive techniques. Phrauders will find advanced methods, just like putting pharming functionality into viruses and worms. Strong auth will help a bit, but will not stop the most sophisticated attacks.

6: Strong authentication will get integrated with "identity".

Authentication and "identity" may not be the same, but they cannot be seen as separate. Authentication companies will look at "identity" technologies as a way to sell more of their products. And the authentication products will comoditize. Maybe it will not happen in 2006, but we will eventually buy SecurID tokens in hypermarkets.

7: We will see attacks targeting legacy "trust" mechanisms.

Ever seen the list of "trusted" certificate authorities in your browser? Ever wondered how difficult is to get a false certificate from any of these authorities? Well, I expect that someone will try and succeeds. There was not much motivation yet, as it was easier to steal a password. But once strong auth will be here, man-in-middle attacks will be popular again. And given the cumbersome and not-much-functional revocation mechanisms of X.509 implementations, these attacks may get pretty effective. The year 2006 will be long over when people finally realize that the authentication must be mutual, not only one-way and that the "strong auth" is not a panacea.