In last month's article, I explained the importance of a varied, tailored approach to authentication. I now want to expand on the topic of authentication to introduce the subject of Federated Identity Management (FIM), something that is likely to affect both you and the organizations you work for over the coming years. FIM can be thought of as a mechanism to simplify identity processing across organizational boundaries.

Continuing in the vein of my last article, I return to my favorite movie, Monty Python and the Holy Grail, to explain what this definition of FIM really means. In the movie, King Arthur asks a simple question of one of his lowly subjects he meets by the side of the road. The peasant, named Dennis, objects to the way King Arthur automatically treats him as an inferior. King Arthur explains that he is superior because he is their king. Not satisfied with the answer, Dennis asks, "Well how'd you become king then?" As atmospheric music rises in the background, the king explains, "The Lady of the Lake, her arm clad in the purest shimmering samite, held aloft Excalibur from the bosom of the water, signifying by divine providence that I, Arthur, was to carry Excalibur. That is why I am your king." Dennis immediately challenges with an ultimate put-down remark: "Listen, strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony."

I choose to ignore the political implications of this comment, but I want to dwell on the authentication side of this scene. How does King Arthur justify being the king? Just because his courtiers and knights saw the mystical ceremony involving the Lady of the Lake does not mean that all of his subjects will immediately recognize his position as their ruler. That is one of the basic tenets of FIM: proving to multiple parties that you are who you say you are.

The inter-connectedness of business these days provides many security dilemmas. One of those is the fact that an organization can no longer focus only on its own internal subset of users. Access to applications and databases can come from partners, clients, and affiliated companies. So how should a company authenticate users trying to access its systems? Of course, the classic way, as we discussed last month, is by using some sort of user ID and a password/token/biometric. But that has two major drawbacks: It is another prompt for the user to navigate through in order to get to the data, and for the organization, there is yet another identity to maintain in the user registries.

If we consider business on the Web, FIM is part of a solution to these problems because it enables the sharing of user identities across trusted domains. As an example, let's consider a car manufacturer. When its users validate themselves in the morning, they are permitted to access many of their internal applications through some sort of single sign-on solution. But as part of their daily work, they may need to access other companies' Web-based applications:

• Car dealers, to check on their stock levels and promotions
• Component manufacturers, to review product details and shipping information
• Travel companies, to review and book trips using the corporate travel scheme

Traditionally, for each of these examples (including multiple dealers and multiple suppliers), the car manufacturer's users will need to revalidate themselves, each time entering another user ID and another password. In addition, someone has to maintain the user details on each system the user might touch. FIM, along with associated technologies, allows the car manufacturer to assert that it has correctly validated its internal users so that these ancillary companies do not need to ask them again for their passwords and IDs.

So how might this work, and what benefits are derived from this approach to security? Let's cover some of the concepts behind FIM, and then we will look at an overview of the technology.

What Is FIM?

Conceptually, there are four main areas to FIM: identity mapping, profile attribute sharing, single sign-on, and user administration.

• Identity Mapping--Most people agree that there will never be a solution in which every user repository agrees on consistent naming conventions for each user ID. Therefore, one of the first concepts an FIM solution needs to address is that a user will be called JSMITH in one registry, SmithJohn in another, and even JS992830 in another. Identity mapping joins all of these together.
• Profile Attribute Sharing--Once external users have been authenticated and permitted access to your system, what can they do on your system? The only sensible way to control this is through Role-Based Access Control (RBAC). This means that when the component manufacturer receives a request from the car manufacturer's "Accounts Payable clerk level 2," the component manufacturer knows what permissions to grant to that user.
• Single Sign-on--If the technology can share authentication information across domains, there is no need to ask users to repeatedly enter passwords and user IDs.
• User Administration--Some organizational entity needs to take responsibility for maintaining user ID details, and all organizations involved must trust that administrating company to perform that task correctly and securely.

At this point, it is important that I remind you of IBM's Enterprise Identity Mapping (EIM) solution, which I mentioned last month. Although EIM has nothing directly to do with authentication, it is a powerful enabler to achieve reduced sign-on in the eServer marketplace. In reviewing these four concepts of FIM, we can see that EIM is part of an eServer-centric solution that already mirrors FIM. Not many people realize the power and impact of the EIM technology. (My apologies for the similarity between these two abbreviations. I did not name them!)

Technology Overview

It's not hard to understand the concepts of FIM and the potential behind them, but what about the reality? Is this another security architecture with great promise that will never achieve its true potential? Actually, FIM projects are already starting to succeed in terms of connecting an organization's partners, customers, and employees on multiple applications around the Web. It's not easy, but it's possible.

One reason we are starting to see successful FIM implementations is because of the strength of the standards behind FIM. Obviously, when we talk about connecting multiple user registries in multiple domains, those domains must agree on the structure and content of security and identity data. Several organizations are making powerful strides toward practical standards:

The Liberty Alliance
The Internet2 Shibboleth Project
The OASIS Web Services security standards

The OASIS project has brought forth a specialized framework called Security Assertion Markup Language (SAML). OASIS says, "SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application." As SAML has matured since its launch in late 2002, it has also promoted convergence with the other standards. The current version, SAML V2.0, is already a useable standard.

Maturing standards mean that we can put the technology in place and agree on the necessary relationships. For example, one organization (or more than one for failover purposes) agrees to be an "identity provider" for a subset of users. It is that company's responsibility to perform the user ID administration on behalf of all the domains in the federation. Other organizations within the federation are then just "service providers." It is their duty to allow access to their applications and databases based upon authentication and profile attributes received from the "identity provider."

However, the final challenge to the increase in successful FIM projects is the maturity of the domains involved in the process. The first few successful projects have involved some of the usual suspects--for example, some are in the federal marketplace, where there has been strong collaboration before and there is already the required level of trust. Similarly, some of the major car manufacturers have demonstrated the necessary power to persuade their affiliated companies that they are ideal and trustworthy central identity managers.

But it is not as simple as that. Referring back to my example, does the component manufacturer have sufficient control of its own users and authentication controls that it will be invited to the party by the car manufacturer? If the component manufacturer has a disorganized profile base, with no implementation of an RBAC solution, then including that company as a domain in a FIM project would be dangerous.

But these problems can be overcome. With better internal controls, many organizations can start to look at the actual tools that will make FIM a reality for them. This will be beneficial in many ways:

• To the users--In addition to a better user experience and less frustration, the internal users will see much more cooperation with partners by sensible sharing of common data.
• To the enterprise--The company will benefit from reduction in costs, decreased help desk intervention, and greater productivity.
• To the external client--We can replace the realtor's mantra of "location, location, location" with "single sign-on, single sign-on, single sign-on."

It's in Your Future

Clearly, FIM is a concept that is driven by very powerful motivators for all parties involved in these federated domains. So we have strong, recognized needs. And we have a lot of powerful organizations behind the standards--IBM, Microsoft, GM, AOL, and RSA, to name a few. We have successful initial projects, proving that this is not just theory.

My recommendation is to take some time to look at this area of security and see how it will affect and benefit you. The links to the standards organizations mentioned above are a good starting point, as is this IBM Redbook: Federated Identity Management and Secure Web Services.

Martin Norman is Senior Systems Engineer for SafeStone Technologies, an IBM BP specializing in compliance and identity management. As one of the original developers of SafeStone's security portfolio, Martin has performed security audits and advised on installations for clients throughout the United States and Europe. Martin can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Authentication and Authorization: Why? Part 3: A Word About Privileged Account Management

Authentication and Authorization: Why? Part 2: Query-Response Language & Policies

Authentication and Authorization: Why? Part 1: Access