Who Really Knows You?

1. I log on to my brokerage account XXX using user name and password.

2. My brokerage account passes me over to another business entity (YYY) with credentials that verify I am a customer of XXX and I am who I am.

3. YYY accepts those credentials, but before it accesses private financial data from XXX, it asks me to authorize that access by entering a PIN.

Welcome to the world of federated identity management (FIM)! As businesses work together to integrate the goods and services they provide, they need to identify unique individuals across company lines and across company databases. Let's see what Wikipedia has to say about federated identity:

oThe virtual reunion, or assembled identity of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of a common token, usually the user name.

oThe process of a user's authentication across multiple IT systems or even organizations.

FIM has been around for years, although it may not always have been called such. I can use my debit or credit card to obtain cash all over the world. I slide the card into an ATM in Rome, enter my PIN, and instantly get a handful of euros. The banking entities of the financial service industry work together extremely well to take care of each others' customers. They have no choice–the original reason for banks of any kind was to eliminate the need for travelers to carry money in an era when highway robbers were armed men, not oil companies.

Acquisitions, mergers, and consolidations are just a few of the issues forcing all financial service providers to consider the best-of-practice solutions to single sign-on and authentication systems. When we discuss FIM, we generally are concerned with management of our customers. But what happens when we acquire another business? Not only do we need to manage a new customer database, but we also need to manage identity for all the new employees. In an acquisition or merger, one existing system probably is going to be adopted across the enterprise, thus forcing one of the parties in the transaction to change perhaps radically the way it does business. Wouldn't it be nice if there were standards for FIM that would allow different systems to work together easily?

SAML is an XML standard for exchanging authentication and authorization data between security domains. SAML is a standard maintained by OASIS (Organization for the Advancement of Structured Information Standards), the global organization that develops and recommends standards for e-business. SAML assumes two entities: an identity provider and a service provider. We also will refer to the identity provider as a service consumer. My employer may have a link directly from our corporate intranet to access my 401K plan, which is hosted by another firm (the service provider). This implies a two-way Web of trust–that the service provider will protect my fellow employees' privacy and that the service consumer will pass only properly authenticated enrollees through to the service provider.

There currently are three versions of the SAML specifications in the wild–1.0, 1.1, and 2.0–and they all have three basic and essential components called assertions–authentication, attributes, and authorization. Authentication validates the user. Attribute assertion provides information about that user (the user may not necessarily be a human; another computer can be a user). Authorization asserts what the user is authorized to do. So, in the case of the 401(k) plan, I am authenticated as being Paul Rolich, an authenticated employee. An attribute such as my Social Security number or plan enrollment number may be passed as an attribute, and an authorization assertion states I may have read-only access just to the account associated with the asserted attributes.

SAML works with all expected protocols including HTTP, SMTP, and FTP. It can be used with SOAP (Simple Object Access Protocol) and is expected to be compatible with BizTalk and Electronic Business XML (ebXML). In short, it is an XML standard designed to work with all current Web service standards.

Another source of FIM standards is the Liberty Alliance Project, which was formed in September 2001. Its goal is to deliver and foster standards for federated identity and identity-based services. The alliance is delivering specifications and guidelines to enable a complete network identity infrastructure that will resolve many of the technology and business issues hindering the deployment of identity-based Web services.

Implementation standards, while essential, are not particularly interesting. What is it we really are trying to accomplish with FIM, and what are the underlying assumptions? We expect single sign-on solutions within the enterprise. Once I log on to my network, LDAP services authenticate my identity and provide positive control for access or denial of corporate Web via a token placed on my machine and local data stores that define my rights. Once I leave that domain, that token (which could be just a session cookie supplied by my intranet) no longer serves to identify me. Consider a very simple example:

Company Alpha has purchased access to a valuable and pricey resource from Company Bravo for all its employees. Company Bravo allows access to that product for only authenticated users. It authenticates users by forcing them to log on the resource with a user name and password. Company Alpha refuses to subject its employees to a log-in screen. This little dilemma can be a little tricky to solve. Obviously, Bravo must provide a mechanism to allow a bypass of its usual user name-password security system so a user just clicks through http://somelink.com and is automatically authenticated.

That opens up the door for abuse of Bravo's resource with the result Bravo must have some way of authenticating the user really is coming from Alpha's intranet. It could parse the request for the HTTP header and determine the request truly is coming from the IP address associated with that intranet. It could have Alpha pass an encrypted token along with each request. That token could be encrypted with a private shared key. It could attempt to use third-party cookies or create a special sub-domain just for authentication. There are undoubtedly dozens of ways to configure this type of access control, but there is one common requirement: We want to find a way to use a single sign-on solution to control identity and authorization management across domains. We also are making a tacit assumption Bravo has a sufficient level of trust in Company Alpha it will:

1. Properly authenticate only authorized users.

2. Properly control access to Bravo.

So, we are not just saying, "I trust you." We also are saying, "I trust your system." That's a lot of trust. Even if Alpha and Bravo had fully compatible FIM systems, there still would be a need for Company Bravo to make that leap of faith. Any FIM system requires one agency to provide primary authentication. In fact, SAML does not even specify how local authentication services are implemented. In a peer-to-peer business arrangement, should we always assume the service consumer provides first-tier authentication? What do we do about individuals–users who are in multiple user databases across a P2P business network? Is there any reasonable way to know John Q. Public in Bravo's database is the same as the John Q. Public in Alpha's database?

Until we have some unique identifier we can attribute to an entity, we will continue to have a certain amount of uncertainty. And that may be fine. We have become a nation of paranoids–unwilling to use our Social Security numbers for fear our identities will be stolen, unwilling to submit to any kind of national identity database for fear Big Brother will get us. We seem willing to accept Globally Unique Identifiers (GUIDs) such as the 12-digit MAC associated with a network card, but we stop short of being willing to identify ourselves. Trusted authentication authorities sharing authentication across business partners is a very cool idea that probably will never happen. Too bad. But that doesn't mean we still can't have a lot of fun with FIM right now. There are a number of commercial applications out there supporting the OASIS and Liberty Alliance standards. Take a look. If nothing else, it might provide a way to consolidate identity management across your enterprise.

As for me, Big Brother already has my number. You can go ahead and implant an RFID in my head–just as long as it is Bluetooth capable and I can listen to my IPOD without headphones.