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

Pattern Language

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.

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.

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?

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

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. Multiple Agent

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. 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 ?? Trust Negotiation

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 Federation

Add OCL constraints… A user must be trusted by at least one web service

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 Federation

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 Confidential Message [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 Message with Integrity[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 Authenticated Message Source [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 Non-Repudiated Message[1]

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, [3] H. Skogsrud, B. Benatallah, F. Casati, "TrustServ: Model-Driven Lifecycle Management of Trust Negotiation Policies for Web Services":