Security Patterns for Web Services

1. Security Patterns for Web Services 02/03/05 Nelly A. Delessy

2. Pattern Language

3. XML Firewall • Intent: To filter XML messages to/from enterprise applications, based on business access control policies and the content of the message. • Context: Enterprise applications executing in distributed systems accessed through a local network, from the Internet, or from external networks. • Problem: Some enterprise applications use tunneling into authorized flows (HTTP, SMTP,…) to communicate with the outside. They use higher level protocols such as SOAP and communicate through XML documents or XML-wrapped remote procedure calls. The XML content of these messages can contain harmful data and can be used to perform attacks against applications.Network firewalls provide infrastructure security but become useless when these high level protocols and formats are used.

4. XML Firewall

5. XML Firewall • advantages: higher level of security than the Application Firewall for inputs which are XML documents or requests. • liabilities: • bottleneck in the network • intrusive for existing applications that already implement their own access control or their own filtering. • The application firewall needs to manage the corresponding cryptographic keys necessary to encrypt/decrypt data, or verify digital signatures.

6. Multiple Agent • Intent: To enforce an organization’s security policies for every valuable resource of the computer system (applications, hosts, subnetworks). • Context: Computer systems logically consisting of several applications executing on various hosts and partitioned in subnetworks. The applications are executing in distributed systems and are accessed from the local subnetwork, the Internet, or other subnetworks. • Problem: It is crucial that these security policies are enforced throughout the computer system. A Security Reverse Proxy can enforce access security policies at the boundaries of a subnetwork, by typically filtering requests going through it. But each application and each host may be accessed through internal networks and a reverse proxy could not be sufficient to block attacks coming from them. Besides, how do we enforce other types of security policies?

7. collaboratesWith * * Multiple Agent Client Resource * accesses * * 1 * Application Level Implementation Level Policy Referential * uses * enforcesPolicyOn Support Agent Enforcement Agent 1 Security Agent * accessesThrough protects SecurityMultiple Agents System * *

8. Multiple Agent • Advantages: • The solution is non-intrusive for the computer system. • The security checks can be applied to a variety of specific technologies by the means of specialized agents. The solution is flexible. • The enforcement system is separated from the referential for the business policies. Thus a change in business policies won’t affect the enforcement of these policies. • The security checks won’t create a bottleneck in the network. • Computer System is more secure, as the application is protected from the calls coming from all internal networks. • Liabilities: • The number and the variety of agents necessary may make the system expensive to develop, deploy, and administrate. • The system is not scalable, as for each new object to be protected, we need to add a new agent.

9. Trust Negotiation • Intent: To establish a trust relationship between a consumer and a web service. • Context: Consumers use automatic service discovery to access a web service. • Problem: The service or the consumer could both be malicious. How is it decided whether or not the consumer should access the web service? • Forces: • The identity of the consumers may not be known in advance by the web service. • The security policies of the user and the web service could be expressed in different ways.

10. Trust Negotiation

11. Trust Negotiation • Consequences: • Consumers do not need to be identified to access a web service. • A variety of policies could be processed. • Known uses: • WSPL • WS- Policy ??

12. Federation • Intent: To realize propagation of the trust among separate web services. • Context: A set of web services in different security domains are accessed by a variety of consumers. • Problem: A consumer could be malicious. How can he be authenticated or authorized to access a service whereas he is not known in the security domain? • Forces: • The identity of the consumers may not be known in advance by some of the web services. • A consumer may have used several other web services

13. Federation • Add OCL constraints… A user must be trusted by at least one web service

14. Federation • Consequences: • Consumers do not need to be identified to access a web service. • A trust relationship must exist between the web services. • Known uses: • Liberty • WS- Federation

15. Confidential Message [1] • Intent • Provide a confidential message. • Context • Threat: eavesdropping • Solution • Make it impossible for attackers to get or read any message content by encrypting it and transmitting an encrypted message instead of the original message. • Implementation Options • SSL or XML ENCRYPTION

16. Message with Integrity[1] • Intent • Provide a message with integrity. • Context • Threat: falsification • Solution • Make it impossible for attackers to get any messages, or make it possible for the receiver to detect any changes to the messages by attaching digital signatures to a message. • Implementation Options • SSL, DSIG or MAC

17. Authenticated Message Source [1] • Intent • Authenticate the message source. • Context • Threat: masquerade • Solution • Perform authentication and make it impossible for attackers to get or reuse any authentication information. • Implementation Options • PASS + SSL , PASS + NONCE + ENC, DSIG + NONCE, MAC + NONCE, DSIG + SSL or MAC + SSL

18. Non-Repudiated Message[1] • Intent • Provide a message that cannot be repudiated. • Context • Threat: repudiation • Solution • Add versions for every message to be sent and attach digital signatures to messages using a private key. • Implementation Options • DSIG + NONCE or DSIG + SSL

19. References • [1] M. Tatsubori, T. Imamura, Y. Nakamura,"Best-Practice Patterns and Tool Support for Configuring Secure Web Services Messaging,"Proceedings of the IEEE International Conference on Web Services (ICWS’04) • [2] "Security in a Web Services World: A Proposed Architecture and Roadmap," Apr 7, 2002. • [3] H. Skogsrud, B. Benatallah, F. Casati, "TrustServ: Model-Driven Lifecycle Management of Trust Negotiation Policies for Web Services":