Wednesday, November 29, 2006

Commoditisation of Federated Identity software

Federated Identity software products will be commoditised. OK, so I'm not saying anything anyone couldn't have figured out for themselves. But this will happen much sooner than many of us expect.

Most software eventually goes the way of commoditisation unless the vendor innovates to the point where it morphs into something different. I won't even mention hardware as this market is largely commoditised and vendors are having to differentiate themselves using "bells and whistles" like performance improvements and aesthetic qualities (e.g. an Apple Mac laptop).

Back to software...

Take the following obvious examples of recent times:
  • HTTP web servers
  • J2EE application servers
  • Relational databases
  • LDAP servers
We can probably all agree that these are all are pieces of critical software infrastructure that form the basis of many of our IT environments. Microsoft is a different proposition. It is its own market and should be treated as such. Why? Because they are not known for interoperability. If you buy Microsoft, you will typically have non-commoditised products because they operate the "Microsoft way". ie. they are not like the other products on the market simply because they refuse to be. I don't mean this in a good way of course. It is simply a fact and makes life harder for the IT community at large because of it (unless an organisation goes 100% Microsoft - which is essentially Microsoft's preference).

So why did all these examples become commoditised? Not only did they become commoditised, then did it very quickly. There's 2 common threads between all of them:
  1. They are all essential building blocks for most IT environments.
  2. They all conform to standards.
Point number 2 is the key. The reason for the fast and widespread success of these technologies is the exact same reason why they became commodities so quickly. Open, standardised interoperability begets almost forced implementation of the relevant accompanying technology to "keep up with the Joneses". If you wanted to be able to "e-business-enable" your organisation, you better have an easy way lower ongoing development costs and reduce the risks involved with implementing ever-evolving technologies. Standardisation does that. Every software vendor of note wanted in. They saw these technologies as key pieces of software that would allow them to seed more software on top of them. The Operating system wars of years past were now being fought on a "higher plane" further up the application stack. These technologies put together have become the "operating system" of everyone's "e-business". As far as vendors were concerned, it would cost more in the longer term to NOT be in the game.

So it didn't matter that vendors did not make money from these technologies, as long as it meant they had a seat at the table for future software evaluation activities. In fact, most vendors give their LDAP and web servers away for free, with application servers just trailing behind in the "free stakes". Relational databases aren't explicitly free, but they are usually given away as part of another software offering. Or if someone is willing to go for the SMB option, they could download the open source relational database.

In the Identity and Access Management arena, the LDAP plays a big part. Like I said, this is usually free. Moving up the stack, we get to the meta-directories, synchronisation, provisioning and access control tools. It's been said for quite awhile that the access control solutions around have become commodities. To an extent, that is true. But that's simply what it looks like from the outside. The real reason in my opinion is that IBM Tivoli and CA Netegrity own most of the access control/application reverse proxy market. So if you talk access management, you're probably "standardised" the Tivoli way, or the Netegrity way. I know I'm ignoring RSA Cleartrust, but they have a MUCH smaller market so I'm treating them as a non-factor. In other words, this "commoditisation of access control" is only a perception. I dare say that's not really the case. Can you say "I want an access management solution so I'll do a design and just buy the cheapest product out there and my design will work"? Hell no! You could however, say this if you're talking about an LDAP design or a J2EE design (yes I know there are small differences between each vendor's implementation, but these end up being configuration, deployment/infrastructure and tuning tweaks rather than real business design issues). In other words, access management solutions are not really commoditised. They just seem to be because of the total market domination of IBM and CA in this space. I dare say, it'll be awhile before they truly become commoditised (disclaimer: "awhile" in the IT world is not really that long - I'm just saying this bearing in mind that we're talking within the IT context). XACML will need to be widely adopted and implemented in all access management products before we can say this area is anywhere near being truly commoditised. As for the meta-directories, synchronisation and provisioning tools, it may be awhile longer before we see commoditisation of these things. The next one after access management will probably be provisioning. Why? SPML goes some way towards some sort of standard. Even so, all that does is to give us a standard way to talk to the provisioning endpoints. It does not standardise the provisioning policies, processes, transactions, workflows, roles, delegation, reporting, audit and compliance requirements (and so on) and how they are implemented. ie. all the important business things. So, we have a ways to go here.

Back to my point. The next piece of technology in the Identity space to be commoditised (even before the access management products) will be the Federated products. The reason? Standardisation of the protocols. Yes I know we have a few around today:
  • WS-*
  • Liberty
  • SAML
  • Shibboleth
So there's 4 at the moment. This will very quickly become 2. Microsoft, and the rest of us. So what else is new. Shibboleth is the BIG thing in education circles, but it's essentially SAML 2.0 with some extra bits. Liberty is also a subset of SAML 2.0. So, what are we going to be left with? SAML and WS-*. Non-Microsoft vs Microsoft. Much like J2EE vs .NET. What this means is that we'll be left with everyone being able to "speak" SAML and some being bilingual and able to translate between SAML and WS-* and Microsoft only being able to converse in WS-*. So with everyone being able to interoperate (sort of), organisations will be left with 2 decisions to make. Which protocol to use (maybe both) and which vendor's product to buy or download for free. e.g. if I want to use SAML 2.0, I just need to pick a vendor that supports it. In other words, any vendor not named Microsoft. This means my decision will centre around the price, support agreements, company stability (whether I like them and if I think they'll still be around tomorrow) and business relationships I have with the vendor. Nothing technical in my decision making process. Of course, all the vendors will argue scalability, reliability, product maturity, ease of deployment, references, happy customers, blah blah blah - which is exactly what hardware manufacturers do. Sounds like a commodity to me!

All the identity vendors are in the federation game of course (there's also a few niche players out there like Ping Identity.). They can't afford not to be - except this time, they are positioning Services Oriented Architecture (SOA) as the endgame and saying that Federation is the key to security in the SOA world (it is of course key...if we're talking about identity exchange, propogation and trust - but there's more to security than just identity). So starting at the SOA and web services layer to get the "foothold", they are instead working down the stack. With this, vendors can now work at potential customers from both ends of the application stack. For example, if someone buys the application server, the vendor sells software up the stack leveraging the application server. If someone buys the SOA and federated stuff, vendors simple sell down the stack and push the "tight coupling" and "close integration" aspects of the non-commoditised software products.

I dare say, in a year or 2 the federated identity landscape may look like this:
  • JBoss application server will support SAML federation natively (JBoss is already working on JBoss Federation SSO using a SAML token. It's all Open Source of course...in the JBoss way).
  • BEA WebLogic will follow suit (BEA doesn't have identity products).
  • Microsoft will WS-* the hell out of anything and everything and include lots of "CardSpace working with WS-*" examples to "quick start your customer applications".
  • Apache Geronimo will have some sort of SAML federation extension.
  • Oracle Application Server will ship with Oracle Identity Federation "light".
  • WebSphere Application Server will have IBM Tivoli Federated Identity Manager "express" natively installed.
So which application server do you want? Hopefully it'll dawn on us at the time when we're all feeling a sense of deja-vu why it is so.

No comments: