A new report in InformationWeek by Andy Dornan calls SOA security "one treacherous journey."
Vendors and committees have thrown a bewildering plethora of immature or incompatible security specs and solutions at us
Treacherous indeed. SOA increasingly addresses services on both sides of the firewall, and therefore opens up the most critical business processes and data to outside intrusion. As frequently mentioned in this blogsite, there's more convergence with Software as a Service and Web 2.0 -- which open up things even more to outside influences.
Andy Dornan's article provides a great, and one of the most comprehensive, overviews I've seen of the issues now facing SOA security. The prognosis: we've got a long way to go, because vendors and standards committees have thrown a bewildering plethora of specs and solutions at us, many of which are immature or incompatible.
Andy notes that choices around SOA security are harder because the market is in such a state of flux. XML firewalls or SOA security gateways were one snap-on solution, but "this product category is disappearing thanks to ongoing SOA consolidation," Andy notes. The functionality is being rolled into "everything from management platforms to core switches."
Then, there is the question of supporting all the different standards promoted by different vendors. Encryption and authentication are examples of this. Another problem area is identity management, which has two incompatible standards -- SAML (Security Assertion Markup Language), supported by almost everyone except Microsoft, which favors the newer WS-Federation. WS-Trust also competes with SAML.
WS-Security offers a strong solution for many implementations, with one catch -- its a SOAP-based protocol. Those running REST need to stick with SSL, or come up with their own security protocols. Plus, matters such as authentication, authorization, accounting, and policies need to be addressed through other standards.
Andy also provides a run-down of the leading SOA security standards (link to his complete list here):
WS-Security 1.1 (link to PDF document): Now an OASIS standard; provides a set of mechanisms to help developers of Web Services secure SOAP message exchanges.
WS-SecurityPolicy 1.2. OASIS work in progress; defines a set of security policy assertions which apply to Web Services Security: SOAP Message Security, WS-Trust, and WS-SecureConversation.
WS-SecureConversation 1.3: Also an OASIS work in progress; built on top of the WS-Security and WS-Policy models to provide secure communication between services.
WS-Trust 1.3: Another OASIS work in progress; uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains.
WS-Federation 1.1: Defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes, authentication between participating Web services.