quotes from an article about how to setup single sign-on with alliance partners in a short time frame

1. From CSOonline.com
The Truth About Federated Identity Management
When it comes to setting up Web-based single sign-on, the security
benefits—and potential drawbacks—are not what you might expect
By Sarah D. Scalet
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, 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."

2. 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 the 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 Federation 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 CSOonline's look at the basics of identity
management, see "identity management in the real world."
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.

3. 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

4. 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-Federation—nor, 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 McGrawHill 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.

5. 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."
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 authentication—it merely fixes a problem.

6. "[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.

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

8. 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."
Senior Editor Sarah D. Scalet can be reached at sscalet@cxo.com.
2002-2006 CXO Media Inc. All rights reserved.
Reproduction in whole or in part without permission is prohibited.
Dated: October 09, 2006