|
When it comes to security, the issues usually revolve around confidentiality, authentication, integrity, non-repudiation and authorization. However, Web services bring additional challenges to the security landscape. A few things to keep in mind:
- Application, Platform and Transport Independence: Web services systems are meant to be distributed, federated and heterogeneous. You'll want to make sure that your security spans all your Web services, regardless of what those Web services are built on, the applications they interface with and the underlying transports that are used.
- Flexibility: Your security must provide fine-grained control of any Web service operation, be enforced at any point that it is needed and be appropriate for requesters both inside and outside your organization.
- End-to-end Security: You need to allow for the participation of intermediaries, without jeopardizing your business-critical systems
- Leverage Existing Security Infrastructure: No sense in starting again from scratch. Instead, you'll want to integrate with your existing systems--authentication, transport, LDAP, etc.
- Standards: To ensure system interoperability, your security must be based on existing and evolving standards
Without addressing these security concerns, most enterprises are restricting Web services to pilot projects or to applications that do not extend beyond their firewalls. The good news is that much progress has been made in developing security standards to stem these concerns. Additionally, the structure of Web services messages makes it possible to leverage mid-stream message content (e.g., order size) and context (e.g., user identity or time-of-day) to apply additional security measures.
Where should you start? Probably with authentication. If you don't know who the requester is you aren't going to be able to address further security issues--unless you're happy with an anonymous SSL connection, that is. You have to decide what authentication mechanism makes the most sense in your environment and then determine if it properly integrates with your Web service infrastructure. (No point in deciding to use certificates if your infrastructure doesn't easily allow certificate-based authentication for your services.) Once you have an authenticated user, the next likely problem is authorization--who can do what. It's likely you will need to do something more complex than "user X can send a message to service Y." You may need the capability to say "user X can send a message to service Y only if the message containing data X is authorized to update." Once basic authentication and authorization are in place you can address additional security issues such as support for Web services intermediaries, encryption and signature of SOAP elements and non-repudiation.
Standards bodies such as OASIS, W3C and IETF are working with major platform and security vendors (IBM, Microsoft, Sun, BEA, VeriSign, Netegrity, AmberPoint, etc.) and customers to create specifications that augment the existing security infrastructures and address some of the challenges faced within service-oriented architectures. A few that are gaining industry traction are XML Signatures & Encryption, WS-Security, SAML, XACML and Liberty.
|
