In-Depth

Q&A: The Future of Service-Oriented Architecture Security

WS-Security, Liberty, and SAML play nice together

• By Mathew Schwartz
• 05/04/2005

Web Services security used to be a jungle. Just a few years ago, when OASIS offered its SAML standard, companies also faced the prospect of having to write to other Web Services security standards, including the then yet-to-be-released WS-Security standard from Microsoft and IBM. (For background on the subject, see “Securing Web Services” in Related Articles, below.)A funny thing happened on the way to Web Services and service-oriented architecture (SAO). Today WS-Security actually complements SAML (and vice versa), and they also “play nice” with Sun’s Liberty Alliance.

To discuss WS-Security and the future of SOA security, Security Strategies spoke with Anthony Nadalin, the chief security architect for IBM software and a co-author of WS-Security.

What’s been the evolution of Web Services security?

SAML came along and allowed us to put tokens in messages that we sent across the wire, but it didn’t allow us to bind tokens to the actual message or protect the message with aspects of the actual token.

Today, however, … if you’re using SAML, you can use WS-Security as the SOAP transport protocol for carrying these tokens back and forth. So if I wanted to do a subject assertion, before, it got carried in a SOAP message. But it was a piece of XML that was in the message, and it didn’t have any relationship to the message itself, because there was no way to bind or apply that token to parts of a message.

When WS-Security came along, however, it said, "Here’s a token, and I can use it to attest to a message, or a part of the body of the message that you didn’t have before." So we’re really seeing that it’s … not an either-or proposition. … What I’m seeing is they end up using both of them in these cases; they’re just complementing each other.

Is using WS-Security an either-or proposition?

Well, as you know, we already had SSL [secure-sockets layer] and TLS [transport layer security], and that will probably stay there forever. Yet we’re finding that in a lot of the financial districts and brokerage houses, many people dealing with transactions aren’t that keen on SSL or TLS. So they look for something at the message layer [such as by using SOAP] to protect [information], because they don’t know if they use intermediaries or not [for transport]. So they make the assumption they’ll use the message layer, [and to do that requires] WS-Security.

What I also see are uptakes on other standards, such as Liberty’s projects, and SAML. But they also based their security model on WS-Security—that’s how they’ll do token exchange … and so this [now] is just how they protect their messages, whether I’m using tokens with Kerberos, or SAML, or just passwords. … So WS-Security has become a really core, fundamental aspect of overall Web Services security.

What are all the parts of WS-Security?

WS-Security is the base. WS-Trust is another specification, which has been out there for a couple of years, and it’s getting ready to go to a standards body soon. Then there’s WS-Secure Conversation, WS-Policy, WS-Authorization, WS-Privacy, and WS-Reliable Messaging.

What’s involved in WS-Reliable Messaging?

We’re making sure we can take security, and compose this with things like transactions and reliable messaging. Because we don’t want to have a world like we have today, where my reliable messaging has its own security model, as do my transactions, as do my messages.

[So] we sat down and looked at reliable messaging and security, and said, "How can I get secure, reliable messages?" and we said, "Here’s a particular pattern you can use to compose the two, so let’s look at the security strengths of this pattern, and other patterns." Then we came up and said, "Gee, here’s what we think is the best pattern with the strongest security characteristics," and so … once this is done, we think security and reliable messaging and secure conversation are in good shape, and can work together.

Have these standards been released yet?

They’ve been produced as draft specs. What we’re doing is looking at our draft processes to make sure they can be made interoperable. … And based on the latest tests, we can guess we’ll be taking this to the standards bodies soon. I can’t comment on a date, but we think we’re getting to the point where we’ve done the best interoperability testing we could have done.

Will these standards work off the shelf for IT managers?

Yes, this is stuff you’ll be able to get out of the box when it ships. We’ve been finishing up the Kerberos interoperability these last couple of weeks.

Also note the WS-Security TC has [its own] standard of making sure we can get interoperability before we go for a community draft. As you know, OASIS doesn’t have any really strict guidelines or restrictions on applications needing to be interoperable. …

But interoperability is vital for usage, so we go through an interoperability [test] prior to voting whether a specification will go into community draft [form] or not. This [means] you can actually implement the specification as released … and it helps eliminate some of the problems people may find during the committee draft-review process. …

Is interoperability a problem for the different Web Services standards?

We do find quite a few bugs, errors, and misprints, especially in the samples [used to verify standards] … but a lot of it is making sure we have a sanity check too. … [For example,] as we’ve done Kerberos, we’ve realized that there are two forms of the Kerberos ticket: one is a raw Kerberos form, and another is a generic, security-services-wrapped Kerberos token. And so far in the spec, we’ve only allowed for the raw token to be moved around, but gee it would be nice if we could also use the wrapped Kerberos tokens [in the future].

How will WS-Security help secure service-oriented architectures?

Now … we have a foundation, or a basic security model, for a service-oriented architecture. The basic security model is that we have tokens, and these tokens represent identity and access-control information for a particular entity. And these tokens are attached to messages, and the messages are then validated … in accordance to a policy that the receiver has.

So you can image that I have this token dispenser—what we call a security token service—and me, being a consumer, before I do business, I get authenticated … and get this token back and place it in my message and send it across in my request. Then the receiver authenticates the token according to the policy it has and does authentication. This is a very simple mechanism, and now this [protects] the message-level side of service-oriented architectures.

What has the Web Services Interoperability Organization (WS-I) done for WS-Security?

WS-I has come along and profiled WS-Security … and they came down to what they think are a core [set of recommendations] for Web Services security: which cipher suite to use for TLS, which encryption [to use], … best practices for signing before encrypting—or encrypting before signing, how you should process your security tokens, what is a standard format for including tokens, [and] do you reference them, or put them in line. … This, I think, helps get the interoperability we need with WS-Security.

Related Articles:

Ten Best Practices to Secure Web Services
http://www.esj.com/security/article.aspx?EditorialsID=1172

Case Study: Circumventing Web Services Security Problems
http://www.esj.com/security/article.aspx?EditorialsID=1104

Securing Web Services
http://www.esj.com/Columns/article.aspx?EditorialsID=96