Top 10 Web service security requirements

No matter how big your company is or what it does, security is a primary consideration when choosing a Web service for all applications. This first in a series of three articles describes the 10 most important factors that determine the security level and requirements when implementing Web services. The second article will discuss how the J2EE platform meets: (a) the security requirements of leading J2EE app servers and (b) how the J2EE platform meets the Web services security requirements of the current state of leading J2EE app servers. The third article takes the same approach with the Microsoft .Net platform.

Security requirements
Before we dive into the 10 most critical factors determining security requirements, let’s briefly discuss Web services security requirements. The key Web services security requirements are authentication, authorization, data protection, and nonrepudiation.

Authentication
Authentication ensures that each entity involved in using a Web service—the requestor, the provider, and the broker (if there is one)—is what it actually claims to be. Authentication involves accepting credentials from the entity and validating them against an authority.

Authorization
Authorization determines whether the service provider has granted access to the Web service to the requestor. Basically, authorization confirms the service requestor’s credentials. It determines if the service requestor is entitled to perform the operation, which can range from invoking the Web service to executing a certain part of its functionality.

Data Protection
Data protection ensures that the Web servicerequest and response have not been tampered with en route. It requires securing both data integrity and privacy. It’s worth mentioning that data protection does not guarantee the message sender’s identity.

Nonrepudiation
Nonrepudiation guarantees that the message sender is the same as the creator of the message. Now that we have an idea of what constitutes Web service security, we’ll examine the top ten security factors affecting Web service implementation.

The top 10 deciding factors
The top 10 essential factors that determine the security requirements for the use of Web services are as follows:

1. Is the Web service being used for EAI or B2Bi?
   Web services can be used for two distinct domains—enterprise application integration (EAI) and business-to-business integration (B2Bi). The security requirements for the EAI domain are a subset of those for B2Bi since it is much easier to control, manage, find, execute, and maintain Web services within an intranet than to use them over the Internet across the corporate firewall. While Web services for EAI should have one level of authentication and rarely make use of encryption, Web services for B2Bi may involve multiple levels of authentication and should always use encryption. Furthermore, in the case of B2Bi domain, the messages corresponding to Web service request and response may need to be encrypted, using one or more of the following: cryptography, digital signatures, and secured socket layer (SSL). However, the use of SSL should be avoided, as far as possible, for Web services used within the corporate network for EAI projects. Lastly, nonrepudiation is useful for Web services in the B2Bi domain since it prevents a malicious sender from later disavowing having created and sent a specific message.
2. What's the purpose of the Web service?
   If the Web service exposes just public information-oriented business process or data, such as today’s weather in a city or a stock quote for a company, the security requirements are looser than those for a Web service that exposes private business information.
3. Who are the subscribers of the Web service?
   Knowing who a Web service’s subscribers are is important for determining the authorization and authentication features of the Web service.
4. Can the service be invoked over the Internet?
   Is the Web service restricted to trusted trading partners, or can any company invoke the Web service over the Internet? This is critical to the authorization and authentication features of the Web service, apart from data protection and nonrepudiation features.
5. How secure is the underlying application?
   What level of access does the Web service provide to the underlying application? Should the access be based on authorization and entitlements? The greater the access to underlying applications, the greater the authorization and authentication security requirements.
6. Is the Web service transaction-oriented?
   The security threats will be higher if the transaction is distributed across multiple entities.
7. What protocol is utilized?
   What network protocol handles the authentication and data transmission between the service requestor and provider? It’s important to know if there’s a need for data security since anyone can sniff the Web service request and response, which would be carried over the network as plain XML documents. If it is HTTPS, then there is no need for any additional encryption/decryption algorithms since HTTPS provides it.
8. Is there a need to verify sender/recipients?
   Is there a need to guarantee that the sender of the Web service request and response message is the same as the creator of the message? This information might be needed for auditing purposes and ensuring that the sender and creator are the same entity. Nonrepudiation security requirements will typically be needed if the Web service is being used for B2Bi.
9. Who is involved in the service?
   How many distinct entities are involved in the usage of the Web service; i.e., does the Web service have an entity-chaining feature? If there is more than one entity, it will require higher security features.
10. Is component chaining used?
    Is there an application- and component-chaining feature in the implementation code of the Web service? If the application chaining spans the corporate firewall, the security requirements become stingier.

It is worth mentioning that, at this stage of Web services, technology standards for security, such as industry standards and support for use of digital signaturesin Web services, are still being defined and worked out. So, stay tuned for the latest developments in the following articles of this series.

Cover all your bases before implementing Web services
Secured interoperability holds the key to Web services’ success in the long run. Be alert to potential security loopholes in Web services since they are vulnerable to a wide array of security threats like denial of service and spoofing. Any implementation of Web services technology should not begin until the above questions have been clearly answered and considered in respect to the security policy and existing solutions within the company.