KeyCorp Unlocks Method for Extending Single Sign-on

Ed Keck likes his company's single sign-on technology so well, he wants to extend it to include his business partners. But while the technology to make that leap isn't a problem, there are some business process issues that aren't so easy to jump.

As vice president of security strategy and governance and lead security strategist at KeyCorp., Keck has been a beta tester for a number of security products from IBM’s Tivoli product line. Now KeyCorp. is working with Tivoli to do something that few financial firms have done before: extend single sign-on beyond its own corporate boundaries.

KeyCorp is a financial services provider with about 19,000 employees and $100 billion in assets. The bank has branches in 26 geographic areas, spanning from New York to Colorado, with New York and Ohio its prime areas. A complex IT infrastructure, with approximately 750 applications running on mainframes, client/server systems, and Web servers, supports the business.

Like many other companies at the turn of the millennium, KeyCorp determined it needed to safeguard its growing number of Internet applications. Deploying and managing the necessary security checks for those applications was a time consuming and tedious task.

To improve its efficiencies, the company wanted to move to a single sign-on system -- and to do that, the bank needed a unified authentication and authorization mechanism. After examining the landscape, (Keck declined to name the other products he evaluated), KeyCorp selected IBM’s Tivoli Access Manager.

"We decided that the least intrusive way to deploy the new security features was to include them whenever an application was scheduled for a new release,” Keck explained.

There were bumps on the road. On occasion, different applications collided because of the way that they used common services, such as namespaces. There were also a few cases where the financial institution’s back-end and front-end interfaces were not as well integrated as the company had hoped.

Eventually, those issues were ironed out. Gradually, KeyCorp. put structured development, testing, quality assurance, and production processes in place, so the security functions were deployed in a consistent manner. About 300 applications, covering most of its major business processes, now rely on Tivoli Access Manager to authenticate users.

The benefits have been significant. Because the bank has standard security services for its applications, programmers no longer have to develop that code and can complete new releases more quickly. Also, employees can enter one password and move from one application to another.

To extend those features beyond its own boundaries, the bank is now coupling Tivoli Access Manager 6.1 with Tivoli Federated Identity Manager 6.0. "Our business partners will be able to securely authenticate themselves with us without having to log in one more time and expose their credentials to the Internet," Keck stated.

The bank has been testing this capability to ease data exchanges with its partners. The testing and design have gone well, but the changes in business processes have been tricky to navigate. Because the financial services company (like any other enterprise moving down this path) is venturing into new territory, legal issues -- such as who owns the password and ID, who can pass what information to whom, and who is responsible if a problem arises -- have been taking time to sort out.

"Working through the contractual verbiage can be time consuming, and you should begin work on it early, so you are ready when the technology is deployed," advised Keck.

The new features are expected to be put into production by the end of the second quarter, making it possible for both external and internal data exchanges to benefit from a federated, single sign-on security system.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.