Using SSL (TLS) for Web Services Security The attached article points out the complexities of implementing SOA security using web services standards. It is however important to note that since externally facing web services typically use the HTTP(S) transport, one can implement Transport Layer Security (TLS) for transport level encryption and authentication - Secure Sockets Layer (SSL) is the predecessor to TLS.
With TLS only the server is typically authenticated. However, with mutual authentication both ends of the conversation are authenticated. This mutual authentication requires the Public Key Infrastructure (PKI). If you have few trading partners this is not much of a hurdle (you can have your partners buy a digital certificate by a recognized Certificate Authority (CA) like VeriSign) if you have many (hundreds) you should consider setting up your own CA.
You can also pass more granular credentials (like a user id and password) in the encrypted messages that can be used to integrate with your internal security system.
This roll-your-own security is fairly simple, but you do give up the long-term benefits of standardization and cannot use more advanced features such as federated security.
If you go the standards route the security appliances (like IBM's DataPower) are elegant solutions that support the layered security concept - a new security layer for web services and XML with a single secure path through the firewall. These devices also have threat protection from malicious XML. This is a good route if you have many unpredicted users of your web services.
SOA SECURITY: ONE TREACHEROUS JOURNEY … Web services have always been sold as a way to share data among organizations: An enterprise can selectively open internal systems to customers, partners, and suppliers, automating transactions that once required human intervention. While most businesses have so far steered clear, keeping Web services tucked safely behind the firewall, the growth of service-oriented architecture and the emergence of Web 2.0 look set to change that.
Will the rewards be worth the risks of exposing internal services to the Web? It's not helping that interoperability woes are exacerbated by the immaturity of SOA security standards. To lock down a large Web services network involving multiple enterprises, everyone must agree on technologies, even security policies: There's no use demanding that your employees use biometrics and physical tokens if a partner's staff accesses the system with weak passwords.
As Chief Technologist and National Practice Director for SOA with Perficient, Inc., I get the opportunity to work with a lot of customers implementing SOA. See my
bio page for my contact information or just post a comment if you want to talk about your SOA projects.
