For years, companies have kept stores of identity information about employees, customers, and partners. These databases and directories are critical components of a company's identity infrastructure. But as businesses push to create new products and increase productivity, they have discovered that they often must cooperate to provide the services their customers and employees demand.

Centralized systems just aren't possible in these cases. Instead, organizations must turn to a decentralized approach, termed "federated identity management." Federated identity systems bring together two or more separately managed identity systems to perform mutual authentication and authorization tasks and to share identity attributes.

To users, federated identity systems present a way for a single identity to be used across multiple systems and services. But behind the scenes, it's more complicated than that. Not surprisingly, the hard part isn't usually the technology. Rather, the hard part is governing the processes and business relationships to ensure that the federation is reliable, secure, and affords appropriate privacy protections.

"There are no commonly accepted best practices, no commonly accepted agreements," says John Jackson, director of software technology at General Motors. "Chances are, one of the parties is doing [federation] for the first time, and the legal implications are not always straightforward."

Complicating your life

Some federations are relatively simple, and as a consequence are easy to govern. For example, if you offer an online service, federating with the identity system of your largest client offers real benefits. The fact that you already have a business relationship with the client makes structuring the federation easy, and such an arrangement rarely involves financial or privacy risks.

Delegating administration of identities to your client means you no longer have to respond to customer service calls about lost passwords. In addition, federation creates value for your corporate clients by increasing convenience and reducing security concerns. These kind of win-win scenarios drive federation.

When a user who has been authenticated by one party takes an action on another site that has real financial consequences, however, the situation becomes more complicated. The problems come down to turf, regulatory requirements, and liability.

For example, federating systems for employee portals raises questions about who owns the data associated with various identities and who has the final say when the data doesn't agree. Ownership issues aren't limited to external partners; federations between the HR and finance divisions of a single company can sometimes be the most acrimonious.

What's more, the regulatory burden can be immense when you're dealing with financial or health data -- both likely scenarios in an employee portal. Global companies have an even bigger problem, given the overlapping and sometimes contradictory requirements of privacy laws around the world.

Employee portals also raise the issue of shared financial responsibility. When a company authenticates an employee for its 401(k) provider, it is saying, in effect, "We vouch for this person." But if something goes wrong and there's a loss, who's responsible? While disentangling a company from the responsibility of providing the outside service is an important benefit of outsourcing, federation requires that the employer take some of the responsibility in exchange for a better user experience and more accurate data.

One of the lessons GM's Jackson has learned in the process of federating third-party services in an employee portal is that legal staff must be educated on the ramifications of federation. On the other side, the service provider must strike a balance.

"You can't be too loose, so as to expose yourself to breaches of fiduciary responsibility," says Roger Sullivan, vice president of business development at Oracle. "But, on the other hand, you can't make it so restrictive that it's more difficult to trade using this automated model than it would be using paper."

Pain points for federation

With governance, there are four primary areas of focus: business issues, liability, privacy, and security.

The business issues can include details of who does what, who pays for what, and revenue-sharing agreements. Most of these are straightforward and are probably already outlined in existing business agreements.

Liability is a tougher problem. Working through the liability issues "ultimately comes down to a common desire by both parties to use federation," GM's Jackson says. "Both organizations have to come to an understanding that it's worth the risk and then work through the issues."

There are no set formulas for assigning risk. "It's largely ad hoc and dependent on the nature of the application and how large the risk is," Jackson says. "A travel application is smaller risk than someone's 401(k)."

Auditing can help mitigate liability concerns. Whether you perform your own due diligence or rely on an external auditor, an audit can convince skeptics that your partner can be trusted with your company's data. Keep in mind, though, that your partner will want to hold you to the same standards. If you're going to require an SAS70 audit of your partner, be prepared to submit your own organization to the same treatment.

Privacy sometimes gets short-changed in IT projects, but you can't ignore it in federation. Many federations include more than mere authentication. The identifying party may be providing personal data to the federation partner, including things like Social Security number, birth date, and even credit card information, depending on the application.

In many cases, use of this data is governed by regulations, especially in Europe and for certain verticals in the United States, such as finance and health. In other cases, you may have promised to protect your customers' data in specific ways; federation requires that these same protections be offered by your partners.

"Revocation of identity credentials is also a key element of any federated scheme," says Scott Blackmer, an attorney who specializes in IT and privacy law. "Otherwise, federation amplifies the threat of fraud, identity theft, and misattribution of content and opinions, as one party after another relies on bad credentials. Federation should include a system for verifying challenges to identity credentials and suspending or revoking them when they have expired or become suspect."

The importance of policy

The ultimate goal of federation is to enable decentralized and distributed identity systems to interoperate in a way that provides all the necessary features for supporting modern business practices. The Internet is the best example of an interoperable, distributed system; protocol and the policies that govern network interactions are the pixie dust that makes it all possible. Similarly, making federated identity work for your organization requires that you pay attention to protocol and policy.

It's important that you choose which of the competing federation standards you'll use and which you won't. Record your choices in a special policy called an IF (interoperability framework). An IF is nothing more than a list that explains what choices the organization has made. It categorizes standards, requiring some and encouraging others. It can also say which standards are sustained but shouldn't be used in new deployments.

Because federation will include outside partners who might have made different choices, an IF should have flexibility built in, including an easy way to get exceptions. A clear benefit of an IF is that it ensures that other policies don't reference specific standards, which could cause them to get quickly out of date when the standards change.

Beyond the technical standards that are critical for interoperability, other important policies govern how the business uses, controls, and protects identity data. Your federation policies should cover how your organization establishes trust in partners, what reviews are necessary for what kinds of projects, and how data will be protected.

How do you get business units to play along? Hewlett-Packard, one of the world's largest companies, has succeeded in creating a federated identity system that contains more than 21 million separate identities and is used by more than 200 different applications that are managed by multiple business units.

"We use carrots and sticks," says Anjali Anagol-Subbarao, HP's chief architect for identity management. "We've shown that using the federated identity management system is about one-third the cost of creating a new system for an application. Since each project has to justify itself on ROI, project managers want to use the federated system." For those who don't, policies from the CIO's office provide the stick necessary to drive the desired behavior.

Anagol-Subbarao also points out the value of outside consultants and analysts. "Getting outside help can validate the system and confirms that the approach is sound," she says.

Where to begin

Many of the companies seeing success in identity federation have one thing in common: They've created a COE (center of excellence) in the CIO's office, a federated identity management council, or both. A COE can help disseminate information, make architectural choices, and educate projects about how federated identity is used in your company. The management council draws business units into the process -- an important step, as most federation governance issues are rooted in the business.

HP employs an architecture council to develop its federation methodology and strategy, according to Anagol-Subbarao. The council employs use cases to create companywide principles that answer questions like: How will users be linked? Is personalization important? How do we provide for auditability?

"These questions have architectural ramifications. We've come up with a strategy for what is important to HP as a business," Anagol-Subbarao says.

Internal SSO (single sign-on) projects are great places to start because they provide a place to choose standards and projects without the pressure from outside partners. Plus, they're likely to show good short-term ROI. The trick is to make sure your SSO projects don't become calls for centralized directories, but rather employ federation technologies to do the job.

Many of the applications that you retrofit for SSO will be Web-enabled. "Start with simple browser-based access to applications inside the corporation," says Timo Skytta, director of Web services at Nokia. Browser-based applications are the low hanging fruit of federation because off-the-shelf identity products from vendors including Oracle, RSA, Novell, and others can often be retrofitted into the server side code with little fuss.

Federation projects within your organization have another big advantage: They force you to clean up your infrastructure. GM's Jackson say's it's the first step, and you can scale from there.

"If you go back five years, we had an uncontrolled number of identity sources, user IDs, and passwords; we even had multiples in single environments," Jackson says. "We had multiple directories in every flavor you can imagine. Over the last few years, we've consolidated directories and the way we do authentication. We felt we couldn't move forward with more sophisticated identity projects until we did that."

After you've got a few internal federations under your belt, it's time to move outside the firewall. Partnering with someone who's already worked through complex federation problems is a great way to learn. Federating with an existing business partner is preferable because you can leverage agreements that you already have.

Interestingly, one of the biggest challenges in federated identity governance is often getting companies to talk to one another. "It's hard to get people to come out and document what they've done because it's a business benefit for them -- the second customer integration [is] much easier," says Nokia's Skytta. The irony is that federation requires sharing solutions. "There are plenty of questions, and no one has all the answers yet."