Identity management for the masses

How Sabre Holdings provides distributed ID management for hundreds of thousands of travel services users

Current Job Listings

Sabre Holdings shares steps it has taken to enable identity management on open systems to hundreds of thousands of users.

Imagine having to provide authentication and authorization services for some 1,000 departments within your organization, while giving about 360,000 administrators control over which individuals get access to what resources. Now imagine that the vast majority of those groups and administrators work for companies other than your own.

That is essentially what Sabre Holdings has to deal with in order to give its clients access to the array of travel services and data that Sabre provides. Sabre Holdings, which spun out of American Airlines, provides travel services such as reservations for airlines, travel-related businesses and, through its Travelocity unit, to consumers. During a presentation at the recent Network World IT Roadmap Conference in Dallas, Kurtis Holland, principal, IT security for Sabre, explained the steps Sabre has taken over the years to enable an extensive identity management capability on open systems. (Compare identity management products.)

“Our main goal is to offload legacy services from our mainframe environment and to maintain the same level of control for authentication, authorization and accountability,” Holland said in a follow-up interview (podcast available here). “That’s a big challenge, considering we peak at 1.5 million transactions per minute across our enterprise – about 25,900 per second – many of which are based on identity transactions.”

In the beginning

Sabre began its migration to open systems in 1998 when it embarked on a plan to implement a service-oriented architecture (SOA) based on Unix and Linux systems and using standards including TCP/IP, IBM WebSphere MQ, and CORBA. The business goals behind the SOA plan included allowing for delegated administration by group and role as well as an identity management service with common APIs, enabling it to be used by various core applications and over any transport. The service also had to support more than 100,000 domains, 200,000 groups and millions of individual user names – requirements that have only grown since. And the identity solution had to utilize a central database and directory service with support for replication and federation.

Sabre Holdings At a Glance

15 million daily travel record transactions, with an average of 471,000 instructions per transaction
250,000+ point of sale devices access Sabre in over 113 countries
400+ airlines
70,000+ hotels, cruise, car, and non-airline content
100+ travel product solutions
2,000 IT Professional Software Developers
1.5 million travel transactions per minute (peak) for shopping, pricing, booking, or fulfillment of a travel related service

At least three types of products are integral to delivering on all those identity management requirements, Holland says: a Web single sign-on (SSO) solution, directory store and a provisioning tool.

In 1999 Sabre implemented Netegrity SiteMinder on its Windows NT systems to provide the SSO function. (Netegrity has since been acquired by CA.) For its directory the company implemented the Sun iPlanet Directory Server (now known as Sun Java System Directory Server).

“SiteMinder gave us the ability to use the native [Sun] directory source, and Active Directory source, as well as integrate an API that’d talk to our legacy [mainframe] systems,” Holland says.

As the number of applications Sabre had to support grew, with more and more of them on the open systems platforms, it became apparent that the company needed a tool to help it automate the provisioning of those applications to users. In late 2004 and early 2005, the company implemented SiteMinder on its Linux platforms and bought another package of tools from Sun, including the Sun Identity and Access Manager.

The Sun tool essentially mimics the provisioning features of the mainframe for an open systems environment, while providing additional features. They include enhanced audit trails and reporting, and a capability to do secondary-level approvals.

But perhaps most important, the Sun tool supports applications written in Java. That gives Sabre the ability to write more and more new applications for its open systems environment. “That allows us more flexibility and faster time to market. We don’t have that many TPF programmers in the world anymore,” Holland says, referring to the mainframe operating system that is geared to transaction processing applications.

How it works

Today, the Sabre environment is a mix of applications running on the mainframe, Linux and Unix systems. Most of the heavy lifting for flight, car and hotel reservation services, such as those provided by Travelocity, has been moved off of the mainframe. Functions associated with the passenger name-record profile, such as booking and ticketing, remain on the mainframe, along with flight operations data.

Some 70,000 businesses or services use those applications, which means certain employees have to be authorized and authenticated. Some may only be authorized to use the applications, others to update content such as schedules, fares and availability.

To handle the mix, Sabre maintains two distinct directories to provide a coarse-grain/fine-grain authorization scheme. The “coarse” profile data is kept primarily in the Sun Java Directory Server, which is used to provide the initial authentication and authorization – letting users in the front door, essentially. Profile data stored in an Oracle database is used to make more fine-grain decisions about whether users can access specific rows or columns of data, or update specific data within an application.

The Oracle database is considered the master database of record. It contains data on some 1,000 domains, 200,000 “branches” or groups, and details what each is allowed to do. Storing such data in a database as opposed to a directory makes it easier to data model and replicate, which is important from both a disaster recovery and federation perspective.

A federated future

Federation, in fact, is the next big challenge Sabre is meeting. It has been using federated Web SSO with many customers for some time, but typically on a one-by-one basis. Some use SiteMinder’s own implementation of Web SSO, others use standards including the Security Assertion Markup Language (SAML), an XML-based standard for exchanging identity data, and others use Microsoft’s Web Services Enhancements (WSE).

But it’s been slow-going on the standards front until recently. “A lot of vendors weren’t talking the same version of SAML or WSE a couple of years ago,” Holland says, noting the standards leave room for implementation flexibility.

Sabre is now trying to migrate its various one-off implementations to true SAML-based connections, knocking them off as customer requirements dictate. “It just takes time. It’s a big world out there with all the different identity providers and access management systems,” he says.

But the technical problems are only the start. “A lot of this comes down to contractual, business language issues around who owns the identity, whether you trust them, what kind of audit trail will be available in the event you need to resolve or review a business transaction,” Holland says. “Overall, the ability to establish trust and reconcile transactions is what has held up adoption of this [federation] process globally.”

Desmond is events editor for Network World and president of PDEdit, an IT publishing company in Southborough, Ma. Reach him at paul@pdedit.com.

Learn more about this topic

Network World’s IT Roadmap event registration/information
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT