Steps to SOA No. 7: Lay your security plans

Years ago, when the industry began promoting Web services, the first objection raised was: What about security? That's because, back then, the emphasis was on XML integration across enterprise boundaries. By contrast, SOA tends to focus on the architecture of a single enterprise -- or closely related enterprises -- where the underlying assumption is that everything occurs within one, big trusted zone.

"Many people have this sense of, 'When I'm doing this kind of stuff inside the firewall, based on restricted network segments or whatever else, I'm OK without a deeper sort of use of security in my services environment'," Forrester's Heffner says. "But the time when everybody says, 'I have to do something with security,' is an external connection."

Although SOA shifts the emphasis toward internal architecture, B-to-B integration with partners is a natural extension -- and in many cases a core benefit. Across firewalls, the solution can be as simple as a two-way SSL connection. But before you jump to any technology conclusions, Heffner advises that you first decide whether your enterprise is a "hub" or a "spoke."

Hubs, says Heffner, can simply lay down the law. "If you're a Wal-Mart, then as a hub, you just say what the architecture is going to be aEuro ¦ because everybody's got to do what you say." For the rest of us spokes, "you've got to look at what your partners, the people you're going to connect to, what sort of security architectures they are doing. And then decide on the strategy of just pure edge security, so you've got an XML security gateway and can do authentication/authorization at that level," or a deeper level of security, where authentication travels along with XML documents as they move within the enterprise.

Fortunately, the industry has agreed on a simple framework for securing XML messages beyond the time when they're in flight: WS-Security, which is perhaps the most often used Web services specification after SOAP and WSDL. Today, many enterprises combine WS-Security with SAML tokens to assert user identity through every stage of a multipart transaction -- an especially useful solution for financial services organizations.

Several other security specifications are in various stages of development. WS-Trust is an extension to WS-Security that ensures the service requestor is properly authenticated before security tokens are issued. WS-SecureConversation extends the trust derived from positive authentication to groups of messages. And WS-SecurityPolicy enables services to exchange security policies and to negotiate authentication and authorization without user intervention. None of these three specs, which will be fairly essential in a world where XML messages routinely cross domains, has yet seen widespread use.

"For us, this is another area where we're struggling through as best we can until new standards and practices emerge to make the job easier," says Bob Laird, IT chief architect at MCI. Meanwhile, Laird is focusing on solid external defense systems, an effort that includes making his existing infrastructure security managers aware of new traffic flows and transactions, and purchasing dedicated SOA defense hardware such as XML firewalls from Sarvega.

"Something bad has to happen before SOA security tools really start happening," Laird says. "We'll see XML-based attacks, maybe even viruses, hitting someone publicly -- and that's what it'll take to galvanize the industry."

Join the newsletter!

Error: Please check your email address.

More about GatewayHISMCISarvegaWal-Mart

Show Comments

Market Place