Using patterns to compare web services standards

1. Using patterns to compare web services standards E. Fernandez and N. Delessy

2. Introduction • WS enable the creation of new applications through web services composition • implement a Service-Oriented Architecture (SOA) • involve a number of web services providers, possibly from different organizations. • these providers may not even know each other in advance, and could discover each other on the fly •  security of these applications is challenging.

3. Introduction • problem with WS security standards: several organizations are involved in developing them • there are many, and they may overlap • Several commercial products,(web services firewalls, XML VPNs, or identity management solutions, ...) implement security for web services • lack of clarity in the web services security standards map  difficult for vendors to develop products that comply with standards and for users to decide what product to use. • Users are also confused when selecting products because it is not clear sometimes what standards are supported by a given product.

4. Introduction • We are developing a catalog of security patterns • Another aspect: how to compare standards using patterns? • Using patterns: • we can verify if an existing product implementing a given security mechanism supports some specific standard. • a product vendor can use the standards to guide the development of the product. • we can compare standards and understand them better. For example, we can discover overlapping and inconsistent aspects between them.

5. Web services security patterns

6. Comparing product architectures to standards • Choose two aspects to compare from the diagram (the implementation of a standard by a generic product) • here the Application Firewall pattern and the XACML Access Control Evaluation pattern

7. Application Firewall

8. XACML access control evaluation

9. Comparison • the structure of the Application firewall pattern is too simple to support a complex standard such as XACML: • the concepts of Policy Decision Point and Policy Administration Point are included in the Policy Authorization Point, • there is no way to handle descriptors for subjects, objects, and predicates.

10. Comparing standards • we choose a pair of standards to compare, we consider XACML Policy Language against WS-Policy.

11. XACML Policy Language

12. WS-Policy

13. Comparison • To compare two standards, we can look for similarities in their context and in the problem they solve. • When they are similar enough, we can compare the way they solve the problem, balance their respective advantages and liabilities.

14. Comparison • These two patterns use policies to solve two different problems. • Also, their context is different: First, WS-Policy is intended for securing Web Services, whereas XACML is more general. • Second, an XACML policy is used by the organization’s Reference Monitor to control access to an organization’s resources (services or documents) whereas a WS-Policy is bound to a specific Web service endpoint. • A WS-Policy policy can be used to expose the web service’s requirements and then can be used in the access negotiation with the requester.

15. Comparison • Therefore, XACML is to be used in a centralized context in which one Reference Monitor controls access to many web resources. For example, an application firewall could use XACML policies, (which are a subset of the XACML standard). • WS-Policy is to be used in a decentralized context where each Web service provider has or implements a Reference Monitor to control access to it. For example, it could be used when an application is built by automatically composing web services from different organizations. Such an application could be a travel agency application that has to contact several flight booking services, hotel reservation services, …

16. Comparison • The problem resolved by WS-Policy is similar to the one solved by WSPL. • WSPL describes accesses as combinations of the requester, the resource and the environment’s attributes, whereas WS-Policy describes accesses in terms of assertions, which is an extensible concept. • Another standard, defined by the same committee, WS-SecurityPolicy, extends WS-Policy and defines the integrity and the confidentiality assertions which can correspond to some environment’s attributes in XACML. • Also, the security token defined in WS-Security can correspond to a user’s attribute.

17. Comparison • However, minor dissimilarities exist between these two standards in terms of: • Attributes/assertion operators: WSPL allows a wide range of comparisons…whereas WS-Policy : “=” • negative policies (only WSPL), • the concept of obligation (only WSPL), • the definition of the semantics for attributes/assertions: An Assertion may be a complex XML type, it is domain-dependent. WSPL assertions are from standards data types, and are extensible thus can be processed automatically.

18. WS-Security

19. WS-*

20. Conclusion • In the future we will continue to compare standards against each other. • We also need to develop more patterns to describe standards such as SAML and others.