• Senior Flash Developer / ...
• Project Manager Operational Systems
• IT Manager / Systems Administrator
• Business Analyst - Integration
• Support Analyst

Hidden challenges of federated identity

Phillip Windley, Information Age

13/06/2006 12:47:48

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.

Centralised systems just aren't possible in these cases. Instead, organisations must turn to a decentralised approach, termed "federated identity management". Federated identity systems bring together two or more separately managed identity systems to perform mutual authentication and authorisation 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, it 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) (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."

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 organisations 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 sceptics 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 organisation 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 US, 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 specialises 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 decentralised 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 organisation 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 organisation has made. It categorises 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 organisation 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 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 behaviour.

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 (centre 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 company-wide principles that answer questions like: How will users be linked? Is personalisation 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 centralised 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 organisation 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 flavour 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."

Phillip Windley is a contributing editor and an associate professor of computer science at Brigham Young University, and author of Digital Identity (O'Reilly, 2005).

SIDEBAR

Scaling a federated identity infrastructure Different kinds of organisations approach the problem of scaling a federated identity implementation in different ways. When you're federating with one or two partners, hammering out the legal arrangements and assigning risk and liability is done one partner at a time. Even if technology standards provide universal system interoperability, the lawyers are likely to approach each agreement as a one-off task. Let's call this model "peer-to-peer federation".

The mobile phone industry has had plenty of experience with this kind of federation. Timo Skytta, director of Web services at Nokia, says: "Federation is nothing new for mobile phone companies. Roaming, for example, works because there's an underlying technology combined with a set of business agreements that spell out issues like who is responsible for paying."

According to Skytta, mobile phone carriers have an advantage over other verticals because many of the agreements and issues involved with federation have already been worked out. Mobile carriers still work mainly through p-to-p relationships, but they use standardised agreements as a starting point. These agreements, worked out by industry consortiums such as the GSM Association, give mobile companies a head start in a negotiation.

But if you're not in a vertical that has model agreements, or if you're federating with partners outside your vertical, the p-to-p approach can become tedious. Scaling to more than a few partners begs for more efficient governance models.

One way to scale up is using a hub and spoke model. Hub and spoke federations happen when one dominant player in an economic ecosystem (the hub) starts creating standard agreements with each of its partners (the spokes) and enforcing them through economic muscle.

Hub and spoke patterns can work well in certain situations: a large manufacturer and its suppliers, for example. The suppliers don't usually have an incentive to federate with one another because the hub -- the manufacturer -- represents the dominant business relationship for each. Thus, the hub sets the standards and creates the standardised agreements.

The hub and spoke model is a natural fit for internal federations. In these situations, the CIO's office can act as the hub, creating standards and agreements in consultation with the various business units. Inter-company federations can be trickier, however, as hub and spoke governance is likely to advantage the hub, which holds the power, over the spokes. Under these circumstances, the companies at the periphery of the system may chafe, and disputes are inevitable.

SIDEBAR

User-centric identity brings federation close to home Federation doesn't have to be a behind-the-scenes interaction between big companies. Lately, an idea called "user-centric identity" has gained traction. It revolves around a few core principles, most notably the idea that users should be allowed to choose which identity credentials to present in response to an authentication or attribute request.

A number of user-centric identity systems are available now, and more are in the works. These range from simple, URL-based systems such as OpenID and LID (Light-Weight Identity), to such commercial offerings as Sxip and Microsoft InfoCard. Harvard's Berkman Center, IBM, and Novell jointly announced a new user-centric system, the Higgins Project, in February.

The idea of choice appeals to most people, but what are the implications of this change?

Suppose I work for WidgetCo, which has federated its employee portal with RetireCo, a provider of 401(k) investment services. Under a standard federation scenario, I would log in to the employee portal, and when I linked out to RetireCo, WidgetCo would send a SAML token asserting my identity to RetireCo's server. If RetireCo needed other data about me, it could request it from WidgetCo.

In this scenario, my involvement is limited to logging in and clicking the link. In fact, the only things that tie those actions to the transfer of my identity data are the policies and security of the employee portal. There's nothing in the structure of the federation that requires my involvement; WidgetCo and RetireCo could exchange information about me anytime they wanted, and I would be none the wiser.

User-centric identity models solve this problem structurally by inserting the owner of the identity data into the transaction. In the user-centric model, when RetireCo needs identity information, the request comes to me. I then choose which credential to present, much like you choose which credit card to present when asked to pay for a purchase.

I might choose to use my WidgetCo identity, or possibly some other credential acceptable to RetireCo. I could set up defaults or rules to process the request automatically. But, in any case, I would choose who has access to my identity attributes and how that identity data is presented.

This change doesn't just benefit the user. There are real advantages for RetireCo and for WidgetCo as well. For instance, in the classic federation scenario we imagined earlier, if WidgetCo mistakenly sends my identity attributes to RetireCo, resulting in a financial loss, WidgetCo has to accept some of the responsibility. But in the user-centric scenario, any such request has been approved by me -- significantly reducing the risk to both companies.