## 3 Access Control and Policies for Web Services  
For distributed systems we can enforce policies by controlling inputs and outputs to the application. This leads to the Application Firewall. Similarly, we can control the sending and receiving between web services of XML documents using an XML Firewall. **Application Firewall [14]:** The application firewall filters calls and responses to/from enterprise applications, based on an institution access control policies. It can be considered a concrete form of the Reference Monitor. **XML Firewall [14]:** Filters XML messages to/from enterprise applications, based on business access control policies and the content of the message. It is even a more specialized version of the Reference Monitor. Our pattern on Policy-Based Access control described above incorporates the concepts of distributed authorization at an abstract level. We also produced specific patterns for the two access control aspects of XACML, as well as their specialization for web services:  
**XACML Authorization [15]:** XACML describes authorization rules that can be composed in a variety of ways. **XACML Access Control Evaluation [15]:** This pattern decides if a request is authorized to access a resource according to policies defined by the XACML Authorization pattern; that is, it is a Reference Monitor for XACML. More specific patterns for access control are defined for web services:  
**WSPL [15]:** Enables an organization to represent access control policies for its web services in a standard manner. It also enables a web services consumer to express its requirements in a standard manner. WS-Policy defines a base set of assertions that can be used and extended by other web services specifications to describe a broad range of service requirements and capabilities, including security, reliability, and others. WS-Policy also provides a way to check the requests made by requestors in order to verify that they satisfy their assertions and their conditions before interacting with the web service:  
**WS-Policy [16]:** Describes how to express requirements that are needed or supported by a web service. For instance, it can indicate that a specific signature algorithm must be used when adding a digital signature. Web services interact with users and other web services. Sometimes users and web services are not predefined and known to each other and a trust relationship must be established before any interaction happens between the participants. This relationship can be defined by exchanging security tokens such as certificates or other proofs of identity or attributes. WS-Trust is a standard to support the establishment of trust relationships between web services. Trust depends also on reputation but this is an aspect not included in the standard. Trust is based on security and other policies to enable requesting and obtaining credentials within different trust domains. Both parties need to determine if they can \"trust\" the asserted credentials of the other party. The goal of the WS-Trust standard is to enable applications to construct trusted message exchanges. This trust is realized through the exchange and brokering of security tokens:  
**WS-Trust [17]:** Provides a framework for requesting and issuing security tokens, and to broker trust relationships [18]. It uses WS-Security to transfer the required security tokens, using XML Signature and Encryption to provide confidentiality. This standard may use WS-Policy to specify which security tokens are required at the target. Other patterns for distributed security include:  
**SAML [18]:** Defines a standard protocol to exchange authentication and authorization assertions. It may use WS-Security standard to protect assertions while they are being transmitted. **WS-Federation:** Defines mechanisms to allow different security domains to federate [19].