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 superannuation 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."