sapienti sat: Making SOA Ready for the Enterprise

Part of the solution or the problem? Probably both…

In my last post I mentioned standards as one of the challenges faced by those trying to build secure SOAs. Don’t get me wrong – I am not against standards as such, they can be very useful and often provide a keystone for interoperability. They also sometimes bring elements of democracy into the industry which is traditionally gravitates towards oligarchy. However in the case of SOA the situation with standards seems to be really bad: there are at the same time too many and too few standards. There are competing standards, some of which were introduced purely for political purposes. There are things which look like standards, but are in fact private specifications backed by one or two companies. There are standards which have no adoption and are unlikely to ever get any because they have not had any activity for three or more years. The same is true for SOA Security standards, yet unfortunately platform vendors have been engaged in a kind of arms race around standards compliance – the longer the list the better [presumably] is the product. Wrong! Standards are important, however, it is imperative to understand that by itself compliance to security standards guarantees neither interoperability nor security. Let me give a simple example.

Once there was a platform vendor in the SOA space, who only supported proprietary or very rudimentary (HTTP Basic, SSL) security mechanisms. They decided that this is not good, and in the next release introduced support of a number of standards including WS-Security, SAML, etc. The resulting solution worked like this: when a service was configured to require security, the platform upon receiving a SOAP message performed the following actions:

1. Look for WS-Security header – check
2. Verify that the header is well formed – check
3. Look for SAML token in it – check
4. Verify that the token is well formed – check
5. Determine the issuing authority – check
6. Present the token to the authority and ask if it is legitimate – check
7. Proceed with the processing of the request.

For those not intimately familiar with how SOA Security works this is basically the right way to implement these standards, however they missed the federation/trust establishment steps that are covered in other standards. As a result anyone willing to compromise such security had to create themselves an identity provider (Sun’s own Access Manager will be a great choice, and I think it is even available for download), issue themselves a token and use it to hack away at the protected services. Needles to say that this resulted in lowered, not increased security compared to old-style HTTP Basic over SSL so in the next maintenance (..1) release the feature quietly disappeared. As far as the interoperability goes, when I am talking about SOA Security I like to ask the audience a question:
Imagine that there were two technical teams of the highest caliber, located at the opposite ends of the world. Both teams read the entire WS-Security specs with all the profiles and supporting documents, understood and implemented them in their entirety and 100% bug-free. And then they tried to interoperate without ever talking to each other [which is exactly the original vision behind SOA that made it so popular in the first place] – and you have to bet on the outcome. What odds would you give them of actually interoperating successfully?
Usually the more person knows about the subject, the longer odd they would give – my current guess is around 15%.

The point I was trying to make is that Standards checklists do not provide a sufficient basis for comparison for products or solutions and are poor predictors of how secure, interoperable and future-proof they would end up being.

Instead of a conclusion, have a look at the laundry list of SOA Security standards compiled by a leading industry analyst and their take on their degree of maturity:

SOA Security Specifications

• WS-Security: SOAP Message Security 1.1
• WS-Security: SAML Token Profile 1.1
• WS-Security: X.509 Token Profile 1.1
• WS-Security: Username Token Profile 1.1
• WS-I Basic Security Profile 1.0
• WS-I Basic Security - SAML Token Profile
• WS-I Basic Security - X.509 Cert Token Profile
• WS-I Basic Security - Username Token Profile
• SAML 1.1
• XML Encryption
• XML Signature
• WS-I Basic Security - Kerberos Token Profile
• WS-Security: Kerberos Token Profile 1.1
• WS-Security: SOAP with Attachments Profile 1.1
• SAML 2.0
• WS Federation
• WS-I Reliable Secure Profile
• WS-SecureExchange
  • WS-Trust 1.3
  • WS-SecurityPolicy 1.2
  • WS-SecureConversation 1.3
• XACML 1.1
• XACML 2.0
• WS-I Basic Security - REL Token Profile
• WS-Security: REL Token Profile 1.1
• SPML 2 (Service Provisioning Markup Language)

Key: proven, ready, contender, risky.

And if you think the list is too long, they have omitted almost a dozen:

• WS-Privacy
• WS-Policy
• WS-Policy Attachment
• WS-Reliable Messaging
• WS-Authorization
• XKMS
• X-KISS
• X-KRSS
• WS-Policy Assertions

Isn’t life interesting?

Please bookmark with social media, your votes are noticed and appreciated: