Web services security check

When you hear that security is one of the missing pieces of Web services, you’re probably listening to a discussion about complex SOAs that demand newfangled security protocols yet to be submitted to any standards organization. Today, most Web services connections, even those that cross firewalls, mirror the Web: a client and a server interacting more or less in real time, with security controlled by the server.

Such simple interactions typically rely on usernames and passwords for authentication and SSL for message encryption and integrity. More complex requirements, such as authorization and nonrepudiation, can be coded within the service applications themselves. To take one prominent example, even Salesforce.com’s S3, a CRM application that relies on Web services protocols, goes no further than SSL over HTTP.

Things start getting more complicated when at least one of three conditions are true: 1) The architecture includes intermediaries (that is, messages must be carried across multiple hops); 2) messages are stored and must be secured beyond the time during which they’re transmitted; or 3) more than one party wants control over some aspect of the security (for example, the usernames and passwords defined by the client must be used to access the server, which has an independent concept of authentication). This is the point where the newer security standards and protocols come into play.

WS-Security is the premier Web services standard that handles more complex authentication, confidentiality, and integrity for SOAP messages. It supports passwords, Kerberos, X.509 digital certificates, and virtually any other authentication scheme. It’s an OASIS Technical Committee specification, has virtually no competition, and has already been implemented by BEA, Microsoft, IBM, and others.

But WS-Security is just a framework within which authentication and authorization take place, most often via security assertion. An assertion is a formal declaration of some information — say, whether a user is authenticated or what group that user belongs to — that serves as a kind of proxy. For example, an assertion might declare that a client is authorized to use a Web service in lieu of transmitting an actual username/password or digital certificate. WS-Trust is one proposed standard for communicating assertions, but it isn’t as mature as WS-Security. On the other hand, SAML (Security Assertion Markup Language), which predates and overlaps WS-Trust, is already widely used.

Think of SAML as having two parts: the representation of the assertions themselves and a protocol by which they are transmitted. If you decouple the parts, the former can be used in the same way as any other security token (digital certificate, etc.) with WS-Trust. Indeed, a number of early adopters are using this combination, taking advantage of WS-Trust’s more generalized structure. This combination of WS-Trust and SAML is so obvious, it will likely become standardized within the next year.

Using these protocols, two or more parties can hammer out a secure scheme for Web services communications, but the ultimate goal is for the parties’ systems to figure this out for themselves. For such a dream to come true, we need a way to communicate security policy from one SOA to another–that is, to express security requirements and to negotiate options between parties without humans having to work out the details in advance. This is the realm of WS-SecurityPolicy, an addendum to a more generalized specification, WS-Policy. Microsoft’s Web Services Enhancement toolkit already implements WS-SecurityPolicy so that a service can state, for example, that it will accept only requests that are digitally signed using X.509 certificates. A compatible client will understand this requirement and will automatically comply.

There’s some overlap between WS-SecurityPolicy and another specification, OASIS’ XACML (Extensible Access Control Markup Language). The latter is somewhat more mature but has yet to see widespread adoption. Eventually, WS-SecurityPolicy could incorporate XACML as one of its access-control policy schemes, but that solution, like several other advanced aspects of Web services security, has a ways to go. The next phase of Web services security, in which SOAs express and negotiate security policies automatically, remains another year or two away.