## 1 Introduction  
Service-Oriented Architectures (SOA) and web services are special cases of distributed systems. Distributed systems are typically heterogeneous systems that are accessible to a wide variety of users, including institution partners, customers, or mobile employees, which introduces a large variety of security threats. To protect its assets, an organization needs to define security policies, which are high-level guidelines that specify the states in which the system is considered to be secure. These policies need to be enforced by security mechanisms. In large organizations, the policies may be issued by different actors making their management difficult. Moreover, they need to be enforced for a variety of resources. To make things more difficult they may have to follow regulations. A way to allow interoperability and apply security is the use of standards which define architectures to enforce that all participants will follow the same rules in their interactions. Security mechanisms and standards can be conveniently described using security patterns. A _security pattern_ extends the idea of design pattern [1] to describe security mechanisms that can handle some threats [2]. The use of patterns is very convenient for software developers who need to add security to their applications but are not experts on security. Security patterns abstract the key aspects of a security mechanism and can thus be applied by non-experts. They can be used also for guiding product developers who need to follow specific standards. Another use is for evaluating existing systems. We have also found them very useful to teach security concepts. A good catalog is fundamental for the use of patterns and it is important to add more patterns to the existing collections [2, 3]. Web services is an area where patterns have proven useful. In particular, there are many web services security standards, which are rather complex and sometimes overlap; representing them as patterns makes them easier to understand and to compare to other patterns. We survey here our work on security patterns for web services and their standards and we put them in perspective with respect to each other and to more fundamental patterns. Our objective here is not to describe each pattern in detail, for that the reader is directed to the references, but to show which patterns exist and how they relate to each other. We are not presenting here new patterns but surveying and evaluating our previous patterns. The patterns presented here are part of an ongoing catalog of security patterns [3] and we relate them to other patterns using pattern diagrams. As far as we know, ours is the only catalog of web services security standards. However, pattern catalogs are not very useful without a way to apply them to build secure systems. We have developed a general secure systems development methodology [4], which in principle applies also to web services; we specialized it for SOA [5]. As indicated, web services standards are rather complex and verbose and it is not easy for designers and users to understand their key points. Web services standards are typically long documents, e.g., the XACML 3.0 Core Specification is 150 pages long, written to be comprehensive but not easy to understand, and using a combination of XML, UML, and natural language. By expressing web services security mechanisms and standards as patterns, we can verify if an existing product implementing a given security mechanism supports some specific standard [6]. Inversely, a product vendor can use the standards to guide the development of the product. By expressing standards as patterns, we can compare them and understand them better. For example, we can discover overlapping and inconsistent aspects between them. A standard defines a generic architecture and this is a basicfeature of any pattern; it can then be confirmed as a best practice by looking at products that implement the standard (and implicitly the pattern).