Depending on who you ask, Service-Oriented Architecture (SOA) security is either a pressing problem the industry still must come to grips with or something that’s been fixed since the client/server era.

With client/server computing, the mainframe was seen as the giant server providing server functionality to myriad distributed clients. If you use the same analogy, the mainframe today is poised to play the role of the giant services provider to various flavors of distributed systems consuming those services.

Still, many mainframe data center managers were never comfortable with client/server computing. They were reluctant to open their core mainframe systems to all these clients distributed throughout the enterprise and beyond.

Attitudes haven’t changed much with the advent of SOA. Services, at least the reusable ones, take on a life of their own. In theory, people who may not be disciplined IT professionals can create composite applications by reusing various combinations of services. The customer shipping address service initially created for use with the distribution center system, for instance, could suddenly be re-combined with other ser vices to make a completely new application that has nothing to do with the distribution center. Who are these people and what are they doing with my precious service and data? It quickly becomes apparent why mainframe managers are nervous about SOA.

“Security always comes up when we talk about SOA,” says Robert Morris, senior vice president, GT Software, Inc. “There isn’t a customer who doesn’t have concerns.”

The industry recognizes security as an essential ingredient in the SOA mix. Already, SOA planners can take advantage of well-tested, standardized security protocols and more granular security protocols are in the works. Similarly, tools from vendors such as GT Software, SOA Software, Forum Systems, Infravio, and others help companies expose pieces of mainframe functionality as reusable services while incorporating the latest Web Services and SOA security protocols as they interface with IBM’s RACF, CA-Top Secret, and other mainframe security tools.

As a result, SOA might even be considered more secure.

“You end up creating an additional layer of security,” says Walid Negm, vice president, Forum Systems Inc. That layer of security typically takes the form of XML firewalls and SOA gateways, which inspect messages passing to and from the mainframe and enforce policy so only appropriate, policy-compliant traffic gets through.

A Question of Trust

Security is a concern with anything having to do with information systems. No one wants to be liable for the theft of thousands of customer identities or the loss of confidential employee data or any of the other headline-grabbing events resulting from an IT systems security failure. Understandably, the urge to tightly lock down the mainframe is powerful.

But business has changed. Today, companies must partner with others, outsource, collaborate, and otherwise share information over the network. Sensitive information, confidential data, and valuable intellectual property must pass regularly between the systems of companies working together. Even customers want a piece of the mainframe as they demand self-service capabilities or want to customize the relationship in some way. All that requires is opening systems to others, both within and outside the company.

The appeal of SOA is that it lets companies extend their systems more easily and quickly than ever, without the costly, painstaking, system-to-system integration previously required. Through standardized, reusable services, each partner becomes a node on the others’ systems.

This requires a level of trust companies previously avoided.

“We need to establish a trusted relationship with each partner,” says Ed Vazquez, group manager for WebSphere integration and SOA at Sprint. That relationship, however, isn’t based on faith. “You need authentication, authorization, and identity management,” says Vazquez.

Sprint’s SOA lets the company securely engage in collaborative activities with many customers and partners through the use of services that access selected functionality and data residing on the company’s many mainframe systems.

Key SOA Security Issues

Beyond authentication and authorization, which typically are handled by tools such as RACF or Top Secret in the mainframe environment, SOA raises several issues relating to the distributed nature of the new operating environment. These include:

• Message security: How do you ensure the message is authentic and hasn’t been tampered with as it passes through and interacts with multiple systems. Where transactions are involved, you also need to ensure non-repudiation.
• Trust: The industry addresses trust and authentication through a series of WS-Security specifications. Security Assertion Markup Language (SAML), another security protocol for establishing trust and authentication by exchanging credentials, uses information from multiple, independently administered sources to enable authorization.
• Distributed policies: Security relies on corporate policies, which specify what can be done with what, by whom, and when. Other policies specify how certain data must be handled, such as encrypting particular data before it can pass through the firewall. Policies also need to specify the governance procedures to ensure, for instance, that the various pieces all use the same encryption algorithms.
• Identity management: Identity is the basis for gaining access to services. However, a typical SOA spans multiple security domains, so various identities may be attached to a single user in different security domains. This must be sorted out.

It’s the distributed approach to these issues that data center managers will find most disturbing from a security standpoint. There’s no single point of control through which every service request and reply must pass. Buttoning down security too tightly risks the loss of speed and flexibility, which would defeat the purpose of going to SOA. Yet without the flexibility and speed achieved through SOA, companies such as Sprint would quickly find themselves at a competitive disadvantage.

Role of Intermediaries

The industry has moved quickly to put together security protocols for the distributed SOA environment. Besides WS-Security and SAML, both OASIS standards, there are XML Encryption and XML Signature from the Worldwide Web Consortium (W3C), WS-Trust, and WS-Federation, and more. The industry has assembled a broad array of security tools for the distributed environment.

“The WS Security standards were designed for distributed services and SOA and are well-thought out,” says Jim Crew, former director of data center infrastructure at Merrill Lynch and now a vice president at SOA Software. At Merrill Lynch, Crew rolled out a high-volume transaction system (more than 2 million SOA transactions a day) using WS-Security. For added protection, Merrill Lynch placed Web servers and application servers in front of the mainframe as intermediaries, giving the company numerous opportunities to monitor traffic and validate authentication and authorization at multiple points along the way.

Intermediaries are central to the SOA security picture.

“An intermediary performs management functions and is driven by policy,” explains Miko Matsumra, vice president, Infravio. “The intermediary, in effect, creates the distributed management environment. You make policy for the network, and the intermediary enforces it.”

The most likely intermediaries are XML accelerators and firewalls, which monitor the XML traffic that’s the heart of the SOA-based environment. They inspect the traffic, check it against policies, and validate authentication and authorization. SOA gateways serve similar functions.

However, “The intermediary is a role, not a product,” says Matsumra. So you can pick products from several categories that will fill the intermediary role by providing a place from which to monitor traffic and enforce policy. The intermediary sits between the service provider and service consumer. Even an Enterprise Service Bus (ESB) can act as an intermediary.

Where the mainframe data center is concerned, the intermediary has an additional task. It must provide a valid RACF, Top Secret, or ACF2 ID and wrap it in the SOAP message. Netegrity’s SiteMinder, now incorporated into CA’s eTrust access control product and IBM’s Tivoli Access Manager, typically handles this chore among large mainframe shops.

Business as Usual

SOA security isn’t so forbidding when the organization uses a product designed to carve SOA services out of mainframe code.

“It turned out not to be any different from what we had been doing with the distributed environment for a long time,” says Terry Nafe, system architect at a large Midwest insurance company with a big zSeries installation.

Using GT Software’s Ivory Server, the company is even writing new COBOL programs to run on the mainframe and to be offered across the distributed environment as a service. The insurance company hasn’t extended its SOA outside the company, which simplifies the security challenge.

“All the applications run inside the firewall,” Nafe explains. “Users sign on and authenticate against Top Secret. The information is passed up to the mainframe for authentication. The service request then runs under a unique transaction ID on the mainframe.”

SOA security augments existing zSeries security.

“You can’t really federate RACF identities,” says Eugene Kuznetsov, founder of DataPower, which was acquired by IBM in October 2005. “Instead, you need to bridge security between the zSeries and the outside systems.”

Kuznetsov now heads up product management for IBM security appliances.

“The appliances sit in front of the zSeries and talk to the SOA applications through one end and to the zSeries through the other,” he explains. IBM has appliances for XML acceleration, a security gateway, and integration.

Security in the SOA world turns out to be not nearly as problematic as mainframe managers initially feared. You lose that single point of control and a firmly locked down environment, but you gain additional layers of security through intermediaries running a growing set of security protocols designed for the distributed SOA environment. With such security in place, the mainframe can confidently assume its new role as the major services provider for yet another generation of systems.