Australia's new Privacy Principles - things to consider

Effective today (12th March 2014), Australia's Information Privacy Principles and National Privacy Principles will be replaced by 13 Australian Privacy Principles (APPs). Here are the important points to note:

• Applies to all organisations that turn over more than $3 million per year and collect personal data.
• Fines up to $1.7 million for breaches.
• Organisations must be transparent about how they collect, use and store personal data.
• Organisations cannot collect data “just in case they need it”.
• If personal data is disclosed to a 3rd party, the organisation disclosing the data is responsible for ensuring the 3rd party understands their obligation and that the consumer knows about the disclosure.

This effectively gives the Office of the Australian Information Commissioner (OAIC) teeth as the fines are now significant when compared to previous legislation. For example, Australian Telecommunications giant Telstra has only been fined a measly $10,200 AUD for their recent violation.

Mindful collection and sharing

The days of "we'll ask for the information in case we need it" are gone. Organisations need to think about what they really need to achieve the task at hand and collect only what they need. As consumers, we should be able to sign up for online services in a shorter amount of time instead of frustratingly getting stuck on a submission form which constantly complains we haven't filled in certain fields.

Marketing programs and processes need to be reviewed to ensure personal data is not being inappropriately shared with 3rd parties. Many companies disregard the flow of information and the lack of visibility & understanding around how this is done, sometimes through no fault of their own. The number of technology integration points involved is challenging, but as privacy is now tied to financial penalties, this is a huge risk to businesses and should be addressed urgently through the involvement of IT departments and potentially external assistance.

If information is justifiably shared outside of the organisation, they will need to have the ability to determine if an overseas 3rd party they are disclosing personal information to also complies with the privacy act. This is a function many organisations will not have and will need to be included as part of their risk management program.

Personal information

In all things privacy-related, things tend to be up for debate, none more so than the term "personal information". The safest way for organisations to tackle this ambiguity is to assume data can be tied together from various sources, even when not immediately obvious as to how, to form context that can be tied to an individual. For example, an IP address is a potential identifier of an individual when combined with information from the relevant Internet service provider.

Personal data can also be stored in unexpected locations that organisations may be unaware of, the most obvious being application logs. IT departments need to perform an internal audit of the information applications use and ensure they are not subject to inadvertent personal data leakage through logs as a result of log file settings.

There is also additional administrative overhead in dealing with personal information and its access. The right technologies and a properly implemented reliance on external information providers can help. For example, power can be given to individuals to have complete control over the information stored about them through self-service portals. In addition, there may not be a need to store certain pieces of information. Standards exist (e.g. pick your favourite federated identity standard) that allow a relying party requiring information about an individual to ask for it from an identity (or attribute) provider and use it in flight without having to store the information on disk.

Beyond the more mature federated identity standards, there are emerging ones such as User Managed Access (UMA) that place more power in the hands of consumers (i.e. the rightful owners of the data). While not yet supported in many technology stacks, the concepts are sound and organisations would do well to adopt the thinking behind what UMA is attempting to achieve in the longer run.

Summary

Australian organisations need to treat personal data like they would financial information. For example, there are a raft of measures dictated by the PCI-DSS standard regarding the storage and usage of credit card numbers. While the number of credit card data breaches have proven PCI-DSS alone does not prevent breaches, existing data protection standards are a good start for organisation struggling to deal with the implications of the new privacy principles. Organisations would do well to adopt many of the same measures dictated by security standards in protecting personal data as a start. As they understand the requirements and data flows over time, more sophisticated security and access management measures can be implemented to round out an evolving security program.

Social identities are becoming our online driver’s licence

Note: This is a companion blog post to an article I wrote earlier this year for CSO Australia. The original essay was too long for an online publication, so I split it up into 2 related, but independent pieces.

For the generation that assumes a priori that the Internet is a tangible, more-essential-than-oxygen component of the air, social networks have become the digital manifestation of their identities as people. Most use each social network for a specific purpose. For example, Facebook content is typically personal and LinkedIn content is almost always professional. Where possible, we try to confine their use within our subconscious boundaries, but they invariably bleed into each other through porous walls. Nevertheless, each is a persona; a one dimensional representation of our real selves.

While online, much of our significant actions require some form of identification: a licence that says enough about us as unique individuals. While we don’t need a driver’s licence to walk along a road, we do need one to drive along it. Similarly, to do anything of significance online, we need to prove who we are to varying degrees; we need a licence that says enough about ourselves to be allowed to perform certain activities.

A majority of our individual activities both online and off can be divided into two categories: transactions and interactions. We transact with retailers, financial institutions and governments. We interact with friends, family, colleagues, employers and government institutions. There are exceptions to these, but a majority of what we do conforms to this model.

The word “transact” in this sense is not always tied to financial activities. Anything that has a negative real-life impact when fraud is committed can be deemed as transactional. In life, our identity matters when we transact and interact with retailers, financial institutions, governments and other people. There is however, a distinct difference in the acceptable forms of identity when comparing transactional activities and interactions which is tied to risk. It is why certain organisations will accept your Facebook account as proof of identity, but others will not.

Appropriate use of social identities

The key to understanding appropriate use for social identities is context. In real life, activities that require proper identification such as a passport or driver’s licence are transactional.

If you analyse the scenarios you are familiar with in dealing with retailers, financial institutions and governments, you will quickly realise that for anything we classify as an interaction, using social identifiers for access is sufficient. For transactions, they are not.

In the Information Security world, this is known as using the appropriate Level of Assurance (LOA) for the appropriate context. A higher LOA is required for transactions than interactions. The progression to a higher LOA is typically achieved using multi-factor authentication. If you’ve ever received a code on your mobile phone immediately after your username and password has been accepted and asked to enter it into a site before it allows you access, you have used multi-factor authentication. The SMS code sent to your mobile phone increases your LOA.

In situations where social identities play a part in the authentication process, they are best used as first level of authentication. As a “lightweight” identity, this provides the personalisation we psychologically crave and the added usability organisations would like to provide. The fact that personalisation provides additional insight to organisations is a bonus for them. When the interactions verge on being transactional, the LOA needs to be raised using either a second factor or a stronger form of identification. In real life, this is best demonstrated by the fact that a driver’s licence is sufficient for entry to a bar but a passport is required to cross international borders.

Excessive collection of personal information

A major concern regarding the use of social identities as a login mechanism relates to the amount of sensitive personal information stored within social networks. Using your Facebook account to login to another site does not necessarily give it access to your Facebook account (e.g. to make updates). More commonly, the login process involves sharing an amount of information about yourself that the site requires.

The word “requires” is used loosely here. Far too often sites ask for more information than they actually need because they can. We have become so accustomed that we accept it as the norm. Bad data collection practices have trained us into accepting additional risk as a condition for using the Internet. In reality, most sites really only need a way to contact you (e.g. email) and perhaps your name. Put simply, a site should only ask for the information it needs for you to complete your tasks.

The breach the Australian Broadcasting Corporation’s website suffered earlier this year is a perfect recent example of data collection misuse. The information stolen included easily cracked hashed passwords and personal details about each person that the website did not need. When we give up our information to an organisation, we almost never have control over anything that happens to it after the fact.

This is something that the Kantara Initiative is attempting to address through its User Managed Access (UMA) work group and the associated UMA protocol. But until this or something like it is mandated across sites that store information about individuals, it is extremely difficult to address the lack of control we have over our personal details and their proliferation.

Note (not part of original blog post): I strongly suggest checking out Ian Glazer's "Big P Privacy in the Era of Small Things" video if you are interested in exploring and understanding this topic in more depth.

Potential benefit of social identities

Social networks have the potential to reduce the number of places that our information is stored. In addition, they can potentially become the gatekeepers to our information. Imagine if the interaction between a social network and another site included the obligation to delete our information upon request by the social network using a protocol like UMA? Better still, what if it required that the information used be transient and disappears when our session with the site in question ends? Nothing actually gets stored.

In fact, some social networks enforce this today, although this is used more as a defensive tactic to reduce the likelihood that a partner site becomes a competitor by replicating all their user data than a way to protect the information for the benefit of users. Sites that do not conform to the policy are unceremoniously prevented from being able to interact with the social network in any way.

There are benefits to be had for the sites accepting social identities as logins too. Studies have shown that user drop-off rates decrease because users no longer have to fill in forms to access the site. Data storage costs drop as a result and for organisations that do not want to be front page news for losing user data, this risk is no longer present.

A driver’s licence is not a passport

We began by referencing the generation of digital natives driving the assimilation of our digital and physical lives. They influence online innovation today through their demands and expectations. They are the demographic many businesses target. As a result, their behaviour shapes the evolution of the online world and by extension, the real world.

The rest of us have to begrudgingly adapt to a reality being built for them. Like it or not, social identities are becoming the Internet’s driver’s licence of choice. However, social identities are not our online passports. The world is not ready for that reality. And unless social networks start vetting people like banks do, that reality is unlikely to ever be achieved.

Identity foundation

You wouldn't believe how often I still have to explain Identity & Access Management (IAM) basics to people. Or maybe you do because you feel like a broken record each time you do it. So I created this to help explain it to someone who knows nothing about what comes second nature to those of us in the security game.

Note: This is a GIF so if you're viewing this through something that doesn't render GIF files properly, it's going to look like an absolute mess. Also, unless you have a magnifying glass handy, I suggest clicking on the image for a slightly larger version.

Login to the real world with your Facebook account

The following is an excerpt from an article I just wrote for CSO Australia.

Ultimately, context is the key to understanding the appropriate use of social identities. While we may be happy browsing a retailer’s website logged in with our Facebook account for a personalised experience, we are not going to be making the payment with it. Organisations that get the balance right while understanding appropriate use and context can begin their social-enablement journey with their eyes open.

Check out the rest of it here.

How BrowserID works (in Federated Identity terms)

The point of this post is to delve a little into how BrowserID works in the context of what those of us in the Identity & Access Management (IAM) world understand as Enterprise Identity Federation. I'm NOT advocating that BrowserID be used in place of SAML (or any other Federation protocol). I'm merely trying to put on my IAM-glasses and taking a look at the flows in a BrowserID environment.

If you want a less technical, introductory view, read my previous post relating to BrowserID.

Here are the important parts of the "BrowserID dance" and how they map (roughly) to the common terms we understand in the IAM world:

• Email Address - Persona
• Relying Party - Service Provider (SP)
• Email Provider - Identity Provider (IDP)
• Web Browser - Identity Proxy (I know there's not a common definition for what an Identity proxy is but this is the closest I could think of - better suggestions welcome)

Mozilla has specific terms for each of the components, but I've used more commonly understood references to make things a little less confusing. For example, the web browser is officially the "Implementation Provider" in the BrowserID world. Mozilla uses a generic term to allow for the use of something other than a web browser as the medium for accessing an Internet service (e.g. a mobile or desktop client).

The way a relying party validates that you are the rightful owner of an email address is by validating the assertion that is presented along with it. The assertion uses proper cryptographic mechanisms and hence is fairly secure in terms of one NOT being able to generate a valid assertion without being in possession of the relevant certificate (of course, if your browser is compromised, all bets are off). The assertion is signed by the email provider (which as I've pointed out above, is the IDP in the whole scheme of things).

Sound familiar? If you have experience with Enterprise Federated Sign-On concepts, the notion of signed assertions should be second nature to you. The main difference here is that the signed assertion is stored in the browser and presented to the relying party by the browser without necessarily having to interact with the email provider (the IDP). The relying party is then expected to validate the assertion with the email provider before allowing the user access. In a typical Enterprise Federation scenario, the browser is simply a facilitator of information and interactions between the IDP and the SP.

Using Gmail as an example, the (simplified) flow to sign in to myfavefictionalsite.com (obviously not a real site) using BrowserID would go something like this:

1. Visit myfavefictionalsite.com and click "sign in with BrowserID".
2. If your browser is clueless about your Gmail email address, it will ask you for it (if it already knows about your Gmail address, skip to the next step). Once you are signed in to Gmail, the browser will do the "BrowserID dance" with Gmail to get an assertion provisioned to (stored in) your browser for your Gmail email address.
   
3. At this point, your browser knows about your Gmail account and has a valid assertion. It will pass the assertion to myfavefictionalsite.com and you will be registered (if you are a new user) and signed in (after myfavefictionalsite.com does whatever it needs to do to validate your assertion).

Sound simple? Yes, but as always, the devil is always in the details. For BrowserID to work this way, the email provider (Gmail in the example) needs to support the "BrowserID dance". Gmail does not. In fact, I don't know of any email provider that currently supports BrowserID.

This brings me to the fall-back option, which is how the prescribed demo site (http://myfavoritebeer.org/) works. BrowserID has this notion of "Secondary Identity Authorities". The email providers are known as "Primary Identity Authorities". If the email address you are trying to use belongs to a provider that does not support BrowserID, the use of a "Secondary Identity Authority" is used. At the moment, the default is browserid.org.

Mozilla states that anyone can be a "Secondary Identity Authority" if they so choose. A "Secondary Identity Authority" is supposed to hold user information (e.g. username, password, email) and also facilitate the process required to validate ownership of an email address. The typical way to do this is to send the user an email with a validation link which the user must visit. Only when the URL within the link is visited can an email address be designated as valid. In essence, a "Secondary Identity Authority" is an IDP which validates that your email address is actually "owned" by you and also signs you in.

Because there are no email providers today that support BrowserID, the only way a user can sign in using BrowserID is by using a "Secondary Identity Authority".

The best way to understand this is to try signing in to Mozilla's My FavoriteBeer demo. When you attempt to sign in, you will be asked for an email address. The demo's sign-in prompt will wait there until you check your email and click the validation link. Doing so validates your email address and the demo site will proceed to log you in.

I've tried to keep things in this post at a fairly high level in terms of technicality. If you're interested in getting your hands a little dirtier with the flows and specific interactions, the best description I've come across of how BrowserID hangs together is by Lloyd Hilaiel, who works for Mozilla and is responsible for the My FavoriteBeer demo. It's quite detailed and should give those of you interested a lot more "guts" than I have here.

Finally, my previous BrowserID post mentioned a few issues. But I've just come across a question about BrowserID in the IT Security section of StackExchange that has answers which bring up a few more more valid technical issues. Check it out if you're interested in that kind of thing.

BrowserID - The browser as a Federated Identity proxy

The latest and greatest piece of technology doing the rounds looks to be Mozilla's release of BrowserID into the wild. It's even attracted a fair amount of interest outside the Identity & Access Management (IAM) community.

Mozilla pitches BrowserID as "a better way to sign in" using your email address and from the bits and pieces of commentary I've read, a fair number are raving about how great it is. Of course, there are also doubters and the most common question being asked is how it's different from OpenID. In fact, it's such a common question that Mozilla's already posted an official response.

To simplify it, all BrowserID does is validate (or assert) that you "own" the email address being presented to the service (e.g. a website you need to sign in to) being accessed. Whether the service chooses to accept it as a valid credential is completely up to the service in question. It ultimately comes down to trust and whether a service wants to allow you to use a particular email address to sign in. In this respect, it's not much different to using OpenID to sign-in to a site.

Mozilla's response to how BrowserID differs to OpenID touches upon some valid points. But the main advantage BrowserID potentially has over OpenID, is in its ease of use. It benefits mainly from being tied to the web browser, although Mozilla states that this does not need to be the case down the track. I should stress that a lot of the supposed usability benefits are theoretical at the moment because the primary method for using BrowserID is currently not implemented (more on this in a few paragraphs).

Usability in Identity matters (particularly when it comes to consumers) has always been key. If the act of registering or signing in is too confusing or difficult, people will not use it. The fact that Mozilla is trying to make everything happen transparently (and securely) through the browser means that if they get it right, there is very little the user has to do. No longer will users have to constantly get jolted from site-to-site while they complete the "Federated Single Sign-On dance". For someone who does not understand what is going on, it is a very jarring experience and the industry has yet to solve it properly. The closest we've been able to get is Facebook Connect and arguably Twitter's OAuth experience. But we owe the success of those efforts more to brand recognition than any real improvement in the user experience.

In addition, if something is difficult to implement from a development perspective, there is no chance of user adoption because the functionality in question will never see the light of day. I've personally done quite a lot of work in the past 2 years with OpenID and OAuth within a relying party (a service that accepts identity credentials from a separate, trusted site) and it's not the easiest thing in the world to get right. There are various libraries around to make the implementation less painful, but after taking a look at the source code for Mozilla's BrowserID demo site and the way one enables BrowserID within a relying party, I have to commend them for making it easy (side note: Facebook Connect's success can also be partially attributed to the fact they make it easy for relying parties to embed Facebook Connect functionality within websites).

BrowserID-enabling an email provider however, is much more difficult. There is currently no nice, easy way to do it. I'm guessing Mozilla will get around to making this easier in time. Also, email providers are typically large companies (e.g. Google, Yahoo, Microsoft) so if they really wanted to BrowserID-enable their email service, they will find a way to do it irrespective of any difficulties. But therein lies the challenge for BrowserID; getting email providers to support BrowserID. Without their support, BrowserID has to rely on what Mozilla calls "Secondary Identity Authorities", which are essentially email validation services that hold user account details for sign-in purposes. For example, a "Secondary Identity Authority" requires that you sign up for an account with it so it becomes your Identity Provider in the event that your email provider does not support BrowserID (which at the moment would mean 100% of the time). It also performs the sending of emails to your specified email address to verify that it belongs to you before it will allow you to use it to sign on to a relying party. As of the time of writing, the only known "Secondary Identity Authority" is Mozilla's browserid.org (which means it will probably be the default "Secondary Identity Authority" moving forward).

A glaring weakness those of us in IAM will notice with BrowserID is the apparent lack of any way to pass user details from the email provider to the relying party. This may not be a problem in cases where the relying party doesn't need to know anything about a person, but in situations where the relying party wants to store details about a person, they still need to go through a registration process instead of having information approved by the user sent as part of the federated provisioning process (which OpenID, OAuth and Facebook Connect are capable of doing - I'm ignoring SAML on purpose for now because it would be like comparing apples with oranges).

One major issue I noticed was that once your browser has an assertion that you own a specified email address, you are no longer prompted for validation (until I assume the time the assertion expires). I'm not entirely sure if this is just the way it's been done for the demo or if it's the expected norm, but this is bad. Very bad. It may be convenient, but I don't believe the benefit outweighs the security risk posed. Why? Because it gives anyone with access to your web browser full access to all the sites you use BrowserID for without having to know your password. You are simply asked which email address you want to use and if the relying party site accepts it, you're in! Bad bad bad! I'm not aware of any written guidance by Mozilla on when assertions should expire (although I must admit I have not read ALL their documentation), but I hope email providers choosing to support BrowserID set short assertion validation lifetimes.


It's still very early days for BrowserID so it's difficult to be too critical. They're off to a decent start, but do we really need another way to do Federated Sign-On where the main difference is that the browser plays a more critical role? I'm not sure we do. Could we not do something similar with browser plugins built to support OpenID or OAuth? We'll just have to see where Mozilla go with this. If they manage to make registration and sign-on dead simple, perhaps they'll be in with a chance.

Can't we just have a normal flat-screen?

Remember when everyone was getting excited (e.g. TechCrunch, Mashable, All Facebook) about Facebook allowing automatic login using OpenID? While they didn't accept just any OpenID, apparently a handful of well known OpenID providers would work. One of these approved providers was Google (using Gmail).

I dutifully linked my Gmail account to Facebook, logged out of Facebook, logged into Gmail, opened a new browser tab and navigated to Facebook. I waited. And I waited some more. I closed my browser and tried it again. I didn't think it would help but I suppose I was simply doing what Microsoft had programmed into my head from the many years of using Windows; when in doubt, reboot (I use a Mac now, so I wasn't going to go the whole hog and reboot my machine). It still didn't work. So now Facebook had a link between my Facebook account and my Google account without providing me with any benefit. I put it down to a bug or a misconfiguration but didn't care enough to persist. After all, I'd read that other people managed to get it working.

The keyword here is 'automatic'. Facebook's interface does not have a 'use your OpenID to login' link, hence it is important that it be automatic if they want to leverage an external mechanism like OpenID because there is no way for the user to initiate the sign on.

I revisited this supposed feature of Facebook recently because we were doing some testing with Facebook's supposed OpenID capabilities and after some investigation, realised it was still broken. That is, Facebook does not function as an OpenID relying party, even when using Gmail as the provider.

From what we can gather (by reading various bits and pieces), Facebook's auto-login relies on the existence of a browser cookie from its list of approved OpenID providers. In other words, it's a bit of a hack. Of course, they didn't have many other options as OpenID doesn't specify a way to perform automated checking for a user being logged into their identity provider. The obvious problem being that there are a multitude of potential identity providers and this can include ones that the relying party does not know about (side note: this isn't as much of an issue in an enterprise federated context because relying parties usually know where to redirect the user because there is typically only a single-trusted identity provider, which means the user gets automatic single sign-on if they are already signed-in to the identity provider).

I bring up automatic login and Facebook because I came across a rather interesting way that the people over at StackExchange (if you've ever visited StackOverflow, that's them) have chosen to tackle the issue across their network of sites: they are making use of HTML5 Local Storage instead of relying on crappy (and often insecure) browser cookies.

Reading between the lines, the issue they had was a common one many organisations run into. They have a network of sites that use separate identity stores and they wanted to be able to give their users seamless single sign-on while not compromising on usability. The stock standard answer from those in the vendor world would have been: "just use our Federated Identity Manager". Throwing SAML (I'll be referring to SAML throughout this post, but I really mean 'SAML or a similar open standard') at their problem would have worked. But they ended up rolling their own solution.

The open standards zealots out there would be chastising StackExchange for not using a well known, standard to solve their issue. But herein lies to the problem with what we refer to as Enterprise Federated Identity: it's too complicated for many situations. Unfortunately, a common issue is that OpenID on its own doesn't cut it.

StackExchange chose a hybrid model. They leveraged OpenID and layered additional security measures on top of it. While I haven't had the time to analyse their implementation in minute detail, they look to have designed a fairly sound solution. The obvious potential hole relates to how they store their data using HTML5 Local Storage, but at least it's an improvement on using browser cookies (because cookies are sent over the wire while HTML5 Local Storage stays on the client machine).

Of course, if StackExchange ever wants to federate with an external 3rd party, they're going to have to embrace SAML or force the 3rd party to conform to their home-grown solution (unlikely). But as long as their requirements remain within the realms of federating across internal sites, their solution should work.

The use case for federating internally within organisations comes up more often than not. And SAML always looks like a really simple solution when an architect is drawing it all up on a whiteboard. But wait until you talk to the poor grunts who have to make it all work and get their hands dirty (or until you see the invoice for the services).

I'm not advocating that everyone should roll their own federated identity solution. In a perfect world where costs and time are non-determining factors, we would all pick SAML. But we live in the real world and all I'm saying is I understand why organisations (like StackExchange) choose to disregard SAML. This also goes some way towards explaining why Enterprise Federated Identity hasn't taken off the way we all hoped it would. After all, the reasons to use SAML make sense right? Yeah but...

The well-known federated standards we have today are like:

1. A full-sized movie theatre screen (SAML and its variants)
2. A hand-held television (OpenID).

Many organisations simply need a decent sized flat-screen TV for the living room.

Commoditisation of Federated Identity software part 2

I blogged about this late last year and outlined a whole bunch of reasons why I thought this would happen sooner rather than later.

I'm bringing this up again because some of the Higgins and Bandit bunch are talking about a proof of concept they will be unveiling at the RSA Conference next week which shows:

how companies can integrate a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. In particular, the demonstration will have Novell Access Manager authenticate a user via Microsoft's CardSpace using information from an external identity system. In the demonstration, users will be able to access a sample media Wiki and blog using the technology.

The obvious Novell promotional reasons behind this aside, there was a quote from Paul Trevithick (Higgins project lead, amongst other things) which stated:

"One problem in realising the vision of an open-source identity layer is that tends to commoditise existing identity management products, creating a perverse incentive for companies that are in a position to make interoperable identities work."

He goes on to say:

"That may be the reason you hear about interoperability but still haven't seen it. Companies like Oracle and IBM and even Novell have no incentive to do it."

This brings up something I didn't mention previously - the position this puts the big vendors like IBM, Novell, Oracle, Sun etc in. They are all evangelising the need for open standards and interoperability, which is where we all want things to end up. Problem is, the guys holding all the $$$ within the vendors are then put in an interesting position...support these initiatives at the cost of software sales. Because in doing so, they're effectively cannibalising their own market. This is especially prevalent in the Federated Identity space because the whole concept of Federation is built upon open standards.

Like I said before, I don't think they can stop the freight train and the Federated software products look to be next in line for commoditisation.

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.