The Truth About Federated Identity Management

When it comes to setting up federated identity management, the security benefits (and potential drawbacks) are not what you might expect

Aramark, the $11 billion food-service company, would seem an ideal candidate to trailblaze federated identity management—a process that allows business partners to automatically access each other's computer systems—without requiring multiple layers of passwords.

Aramark has the right kinds of clients: universities and Fortune 500 corporations with multimillion-dollar annual catering accounts (and big IT budgets). It has the right kind of e-commerce business model: Every week, employees from 250 companies at 425 locations log on to Aramark's proprietary Web-based software, MyAssistant.com, where they order everything from sandwiches and brownies to conference rooms and microphones. And Aramark has the technical know-how: It has actually already implemented the technology necessary for identity federation, using a tool from Ping Identity. This year, at one customer's request, Aramark began allowing 4,500 of the customer's employees to log on to MyAssistant simply by being logged on to their own company's network.

So why haven't Aramark's other business partners signed up?

Turns out that Aramark, which can make such a strong business and security case for federated identity management, also provides a good demonstration of how few companies are actually ready to forge such close ties—and take such a bold security step—with their business partners.

On the positive side of the ledger, "It takes the onus of security away from us and puts it on the client organization, where it belongs," says Steve Erickson, VP of IT for business services at Aramark (which recently agreed to be acquired by a group of private-equity investors who include the company's CEO), about Aramark's implementation of the technology. "They're the ones who know when an employee leaves their organization. That inherently makes our application more secure, because we can trust the fact that, in the case of this one client, anyone coming into our application is coming in through their network."

However, Erickson also notes, "We've made it known to new customers that we have the capability; everybody's heads nod up and down, but the difficulty lies in taking it to the next step. We've only been in serious discussions about it with three different organizations in the past year. That just makes me think it's a relatively immature market."

Maybe, but it just as well could mean that for all the potential benefits of federated identity management, it may never take off beyond a few niche applications. Indeed, companies are wise to be cautious before jumping onto the federated identity management bandwagon. History is littered with supposedly revolutionary communication methods that sputtered and failed from too few adopters—picture telegraphy, the 1964 World's Fair Picturephone, the satellite telephone. It's anything but certain that federation will ever reach a critical mass, where enough people have it that everyone wants it.

"It's clear when we look at our business demands that federation might provide value," says Chris Gervais, a senior research analyst at Partners HealthCare in Boston, which is evaluating identity federation technology. "But then we have to find someone else to federate with. It's like the problem with the original telephone. It doesn't matter if you have a telephone. It only matters if someone you want to call has a telephone."

What Federated Identity Is All About

Federated identity management isn't a security project, per se. But because federated identity management is all about access, it presents a huge opportunity for security leaders. "It's an enabling technology as opposed to a preventative one, like firewalls," says Bryan Palma, founder of consultancy Ponica (and former CISO of PepsiCo). Because identity management is about letting the right people in, rather than keeping the wrong ones out, Palma says, "it's a place where CISOs can positively impact the business." That's the payoff that CSOs should keep in mind as they sort through the attendant challenges.

Federated identity management requires a complex set of technologies and business processes, but the goal behind it is simple: to automatically share identity information across administrative boundaries. For CSOonlines look at the basics of identity management, see "Identity Management in the Real World." http://www.csoonline.com/read/110104/idmgmt.html

Those boundaries can be between service providers and their customers, as the Aramark scenario demonstrates. One classic example is American Express, whose corporate customers can allow their employees to access travel and expense-management services without an additional log-in.

The boundaries can also be between manufacturers and their customers. Boeing, for instance, has joined with—or "federated" with—airline customers. Mechanics at, say, Northwest, can seamlessly access the most up-to-date maintenance manuals stored on Boeing's servers.

A third kind of boundary is between a company and its outsourcers. One of the earliest instances of this type of federation was at Fifth Third Bank in Cincinnati, which decided to outsource some HR functions but still wanted employees to have easy access to benefits information.

Finally, federation can even connect organizations to themselves. The University of Texas system is in the midst of a large federated identity management project that will link administrative functions at all its far-flung campuses.

From the end-user perspective, all of this amounts to Web-based single sign-on. The user doesn't have to introduce himself to another computer network; his computer (with the help of the enterprise) introduces him to another computer network, by sharing a set of credentials in an agreed-upon format. It's authentication, automated.

Behind the scenes, the standard that usually makes it happen is called Security Assertion Markup Language (SAML)—an XML protocol that can be used to share information about who someone is and what he is allowed to do. SAML "tokens" containing this identity information are passed back and forth between computers on the different networks that are part of the federation. One side serves as the "asserting" party and sends the token. The other side is the "relying" party that accepts the token.

"It makes it sound like one is in control and one isn't, but that's just the terminology," says Jeff Anderson, lead technology architect at Fifth Third Bank, which has three federated identity management implementations deployed already and 11 more in the pipeline. The asserter could be either side, or even a third party. Both parties must agree to allow the access, and either can cancel it at any point. The important thing, Anderson says, is that the asserting system be both trusted and secure. In an ideal (and standardized) world, whole communities of trust could interconnect in this manner with simple and minimal effort.

Needless to say, that's not the world we live in.

A Question of Standards

Depending on whom you ask, there are not one, not two, but three ways of doing federated identity management—and that's an improvement over the way things used to be.

SAML, you see, was created by the Organization for the Advancement of Structured Information Standards (Oasis), a nonprofit group funded by IT heavy hitters such as EDS, IBM and Sun Microsystems that is trying to advance Web services.

Originally, the Oasis work on federation overlapped with work being done by a separate industry group called the Liberty Alliance. Founded by some of the same IT vendors, along with nontechnology companies that include General Motors and Fidelity, the Liberty Alliance had the goal of creating best practices around federated identity management. It created its own way of actually using the SAML tokens that Oasis had established.

The difference between the Liberty Alliance's work and Oasis's work, as described by Gartner VP Ray Wagner, is like the difference between buying a movie ticket and entering a movie theater. "SAML is the movie ticket. The way you walk up to someone and hand them your ticket to get into the theater is Liberty."

The good news is that last year, the Liberty Alliance handed over a lot of its work to Oasis, and now the latest version of SAML (2.0) incorporates those token-handling protocols.

Meanwhile, Microsoft (along with IBM) has created a separate but proprietary

spec­ification known as WS-Federation. WS-Federation allows customers to connect their Active Directory installation with other Active Directory installations, using a product known as—you guessed it—Microsoft Active Directory Federation Services. This system can read SAML tokens, along with other types of identity information (Microsoft calls its tokens Kerberos tickets), but it handles the tokens in a different way.

Although Microsoft has handed Oasis some of its other specification sets for open use, so far it has not released WS-Federationnor, according to a spokesman, does it have any immediate plans to do so. In the meantime, many organizations have been reluctant to build projects around WS-­Federation because of licensing concerns, and have turned instead to SAML/Liberty.

"All the big installations use SAML tokens and Liberty protocols," Wagner says. "Those guys weren't waiting around for Microsoft."

In fact, many say that federated identity management is SAML. "If you talk about the true line of federation, it's really SAML," says Dennis Brixius, VP and CSO of McGraw-Hill in New York City. "Is

[WS-Federation] as good? Probably. Have a number of vendors adopted it? Not quite.

It comes down to, if I want to do A and you're doing B, then we have a disconnect. Could we end up having two? Absolutely. But having two just adds to the cost of doing business."

That cost right now is for tools that speak both languages. Vendors of federation tools—among them, RSA, IBM with its Tivoli product line, Ping Identity, and HP with its acquisition of Trustgenix—are building links to both WS-Federation and SAML/Liberty protocols into their wares. Customers then have to integrate those products with either their identity management infrastructure or whatever application they want to allow users to access.

From a security standpoint, which route any one company should go depends not only on its operating environment but also on its philosophy about the ongoing debate between open-source and proprietary solutions. The more organizations adopt either specification, the more attractive it could become in the future for hackers looking for vulnerabilities.

"It's all about paranoia, I guess," says Martin Gee, founder and CTO of ICSynergy, a consultancy that to date has worked on about nine implementations of federated identity management. "Proponents of open sourcing say that by making everything public, everybody can beat on it [to improve the security]. Others maintain that if it's open, everybody knows how to break in."

Identity Federation Simplified, But Not Simple

Whichever type of implementation your company wants to pursue, the immediate security benefit of federated identity management is also the most obvious one: simplified password management. Users are screaming about the number of passwords they have, and federated identity management offers some much-needed relief.

Just ask Clair Goldsmith, associate vice chancellor and CIO at the University of Texas System Administration, who keeps track of his 75 passwords by saving them in an encrypted part of his hard drive. "I know we're never going to be single sign-on—I'm not nuts," says Goldsmith, whose institution is two years into an ambitious federated identity management initiative. But he also knows that reducing the number of sign-ons is a good way to sell a project.

That's one of the reasons that the university's first deployment of Shibboleth (a version of SAML driven by a consortium of universities) was intended to allow the administrators who run UT's 15 far-flung campuses to gain easy access to the wireless network at the system's Austin headquarters.

"Before, they'd be visiting the administration offices and try to log on to the networks [with their laptops], and they couldn't get on," Goldsmith says. "Then they'd go back to their offices and complain that they'd been at administration the day before and hadn't been able to access the network."

Now, when employees power up their laptops, "what comes up is a local webpage that says, 'Select your home institution,'" Goldsmith says. "You select whichever one. You're diverted to that institution and log on there. Then [that system] passes back to us a particular piece of data that we recognize"—a SAML token—"and we let you on the system."

This makes life easier for both the end user and the help desk, but Goldsmith also feels that it makes the network more secure: The individual is vetted by his home in­stitution, so Goldsmith's staff doesn't have to keep track of who has permission to access university resources. The system doesn't strengthen authenticationit merely fixes a problem. "[Federated identity management] is certainly more secure than having an open wireless network," Goldsmith says.

1 2 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies