The Truth About Federated Identity Management

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.

All of which brings us to the second obvious benefit of federated identity management: easier enforcement of user provisioning. One of the most notorious aspects of managing identities is keeping track of which users have left a company or changed jobs. Even within a single company, this is difficult. Managing to keep track across corporate boundaries can be nearly impossible. Again, federation fixes this problem. “There are plenty of situations where what happens is Company A makes a magnetic tape with user names and passwords, and they send that tape to Company B,” says George Goodman, president of the Liberty Alliance management board, about the security issues that Liberty is attempting to solve. “We’ve heard this many times from people in workshops who say, In the bad old times this is how we did it.'” Now, instead, companies can agree on what identity information needs to pass from one organization to the rest, and do so via a secure channel (HTTPS).

“It’s improving security by not exchanging more information than is truly necessary,” Goodman says. What’s more, the setup makes it easier to audit who has access to what, because all that information is stored in a central place.

Of course, single sign-on can also, in effect, give freer reign to anyone who manages to compromise the network. That’s no small concern, given how damaging insider attacks can be. But this is part of the security trade-off that CSOs will need to help evaluate: Are the security problems that federation solves bigger than the ones it may introduce?

More than anything, federated identity management is about relationships, which always involves weighing risks. “You have to assume that you can tolerate the risk of building that relationship with a third party,” says Gee, the consultant. “In a sense, there could be no security benefits, but you’re building a business relationship that makes sense for your business.”

Building trust, not technology, is often the hardest part of any implementation. Even within one university, Goldsmith has found this to be a challenge. “All the institutions have their own personalities, and now we’re trying to have the institutions trust each other,” he says. “It’s Institution A saying, ‘I have a relationship with Institution B, and I will trust them.’ As we go forward, that’s the only way it’s going to work.”

A Case for the Business

In August of this year, Craig Burma, principal and director of the Milliman Benefit Resource Center, was putting the finishing touches on a new federation project. Burma says he vividly recalls the project’s beginning: the day that one of Milliman’s biggest clients—a top 10 brokerage firm—asked him to provide seamless access to Milliman’s pension services for the brokerage’s customers.

No wonder the memory is so vivid: That day was only 60 days earlier.

“I’m probably a little giddy right now because we’re at the end of it,” says Burma, whose company, among other things, provides outsourced pension administration services that are resold by financial services companies. “It’s been a long haul.”

The brokerage called Milliman and said it was trying to close a deal with a new account. The brokerage would be managing its new customer’s employee retirement plans. But the potential customer wanted its employees to be able to access pension information—which the brokerage had outsourced to Milliman—without needing another password. To do this, Milliman would have to set up a federation that took the identity information that the employees provided to the brokerage, and then use that information to pass on pension information.

“We called them back right on the sales floor where they were making the pitch and said, We can do it,'” recalls Burma. So the pressure to deliver on that promise was great indeed.

He likens the intense process that followed to redirecting traffic while the highway is open. Rather than asking for a user name and password, the pension administration program now checks a central identity store—RSA’s Federated Identity Manager­—to find out who a user is and what he needs access to. “Five years ago, if you would have told me I could trust this [system] enough to show people their Social Security number and the name of their spouse and their pension benefits, I would have laughed you out of the room,” Burma says.

It’s difficult, if not impossible, to measure the cost savings of reducing one sign-on. However, it’s clearly of great value to gain a new customer because of an IT function that you can provide. And going forward, those who’ve drunk the federation punch believe there’s more ROI to come, with a little thing known as stickiness—that is, getting people to order more cookies and conference rooms, because it’s easier.

Says Erickson of the business advantages of Aramark’s single sign-on setup: “We’re in business to make it as easy as possible for people to spend money with us.”

When it comes to security, there may be a payoff for federated identity management, and there may not. “Federation is mostly about A, convenience, and B, business enablement,” Gartner’s Wagner says. “The bump in security is not huge in comparison with the business benefit. We just want to make sure it’s as secure as our systems were before.”

As for the business case? Maybe that’s for someone else to decide anyway.

“The businesses are going to be the ones that ultimately shoulder the cost of doing federated identity,” says Brixius, who is in the process of making sure that McGraw-Hill has a solid internal identity management system in place in anticipation of doing federation in the future. “There’ll be a lot of decisions based on reducing risk, being able to streamline the processes, creating the value proposition for our customers. I believe there is going to be an ROI. The businesses will come up with that. They’ll be the driving force, and we’ll be in a position where we’ll be able to implement that—whether it’s outgoing or incoming—to support the business needs.” n