Security Patterns for Web Services

02/03/05

Nelly A. Delessy

Pattern Language

Trust NegotiationRole-Based Access Control

XML Firewall

Multiple Agent Reverse Proxy

Federation

Confidential Message

Message With Integrity

Authenticated Message Source

Non-Repudiated Message

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

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

ResourceClient 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

Trust Negotiation

-credentials

WebService

-credentials

User

Policy

uses

Agreement

Policy

NegotiationEngine

produces

• 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

Federation

-credentials

WebService

-credentials

User

Federation

trusts

* 1 .. *

* *

• 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, 2002.

• [3] H. Skogsrud, B. Benatallah, F. Casati, "TrustServ: Model-Driven Lifecycle Management of Trust Negotiation Policies for Web Services":