Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

What do you think are the major security concerns for Web Services architecture?

What do you think are the major security concerns for Web Services architecture?

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.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.