As Paris Hilton might say, identity management is hot. It's one of the few security-oriented projects that provides...
demonstrable ROI. Whether you are talking about provisioning, Web single sign-on or password management, it's easy to show how these initiatives will save money and increase customer satisfaction.
But that is only the beginning. Things really start to get interesting when you think outside of the proverbial box. Most identity initiatives are focused internally, but for any company that has many trading partners or lots of customers that interact electronically, including external parties can make the ROI of internal identity pale in comparison. That's what federated identities is all about.
Microsoft's InfoCard and IBM's Higgins Project have gotten people talking about federation. To be clear, neither offers an infrastructure that will quicken enterprise deployment. Microsoft's InfoCard is a Windows application that will use industry standards to manage a federated identity system's credentials. Higgins, the open source initiative, is really an application framework that can potentially utilize an identity infrastructure as well. But because both of these initiatives rely on a standards-based identity infrastructure, they will be initial drivers of federation.
Let's take a step back. Federation provides a set of standards and agreements to define the rules of engagement for sharing identity information between two (or more) external parties. It is not new, but with a new, more mature standard (SAML 2.0) and the advent of both stand-alone and integrated federation capabilities within identity management products, it's now feasible for companies to dip their toes into the federation waters.
For those of you who've been around the block once or twice, federation is very similar to Electronic Data Interchange (EDI). You need a standard language to transfer information between trading partners and you need some type of business relationship defined between the parties to provide the legal fallback when exchanging business related information.
You have lots of choices from a technology standpoint. Your traditional "big stack" identity management players (BMC Software Inc., CA Inc., IBM, Oracle Corp., Hewlett-Packard Co.) have bolt-ons to their products that support the standards and provide the capabilities. There are also federation-specialists like Ping Identity Corp. and RSA Security Inc. In early markets like federated identity, users should strongly consider the specialists; without a big stack to worry about, they can focus on integration and dedicated, specialized support as the technology matures.
Federation standards and practices
As mentioned earlier, the industry has anointed SAML 2.0 as the standard for Web-based federation (with HTTP/SSL as the transport) and WS-* will drive Web services. Both require strong authentication and encryption between parties exchanging information. The standards have defined mechanisms to ensure information integrity, confidentiality and protection, which ensure that the underlying technology is secure, but always keep in mind that even secure technologies can present security risk if not implemented properly.
Still, there are constraints to truly ubiquitous federation, one of which being the absence of third-party validation and trust for trading partners, which will dramatically ease the overhead in setting up federated identity relationships. It remains to be seen whether quasi-government entities, associations or even commercial organizations will fill that role. It's likely to be all of the above.
The business drivers for federation are compelling, and the technology is maturing rapidly. As enterprises begin to deploy identity management, the advent of federation among business partners will generate numerous business opportunities.
But as with every emerging technology, you need to tread carefully. It's best off to start small, focusing on exchanging information that will yield results from a user experience standpoint. The most likely candidate is simple Web single sign-on (SSO) -- either in an external or internal context, such as an external integration effort that would enable a common login between Old Navy and Gap's Web sites. It's a hassle to have to deal with both separately, even though the companies are owned by the same parent.
An example of an internal application would be transparently logging into your company's hosted 401k management application using your Windows login. Another example would be to use the Windows login to access Salesforce.com transparently. Again, having to remember multiple passwords for all of these applications is a hassle. Given the more modest objectives of these "starter" federation deployments, interoperability issues will be limited and within a 12-24 month time period will largely be overcome.
Federation is still early into its deployment, so only early adopters -- and those willing to learn alongside the vendors about what works and what doesn't -- need apply. But as standards mature and inter-enterprise business process integration takes root over the next 24 months, federation will be a key part of every company's identity infrastructure.
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta. Read his blog at http://feeds.feedburner.com/securityinciterants or reach him via e-mail at mike.rothman (at) securityincite (dot) com.
Dig Deeper on Enterprise Single Sign-On (SSO)