Introduction

1. A Trust Model for Web ServicesPh.D Dissertation Progress ReportCandidate: Nelly A. Delessy, Advisor: Dr E.B. FernandezDepartment of Computer Science and EngineeringFlorida Atlantic University, Boca Raton FL

2. Introduction • Dissertation’s goal: to develop a unified trust model for web services • Will indicate how it can be interfaced to existing access control models for web services • Will include trust management through trust policies, and dynamic aspects such as trust negotiation • Using UML and/or some mathematical formalism

3. Agenda • What has been done: Existing Web services Access Control Models: • Patterns for XACML and the application firewall (last semesters) • Patterns for the WS-* Family: WS-Security and WS-Policy • Comparison: Included in the paper: “Using patterns to compare web services security products and standards” • Future work • Other Patterns for the WS-* Family and comparisons (SAML vs WS-Federation, …) with other standards (Spring 2006)

4. (Resource, action, context, effect) Credential types Trust level Assigned trust level Required trust level Trust policies Access policies Agenda • Future work • Formal (Semi-formal?) definition of a model for the interface between trust model and access control model (Spring 2006 & Summer 2006)

5. Agenda • Future work • Define the static elements of the trust model formally (Fall 2006) • Develop the dynamic aspects of the trust model (Fall 2006) • Identify patterns from the model (Fall 2006) • Publish a Journal Paper from one of these steps

6. Using patterns to compare web services security products and standards

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

8. 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.

9. 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.

10. Web services security patterns

11. Comparing product architectures to standards • Choose two aspects to compare from the diagram (the implementation of a standard by a generic product) • We consider here the Forum XWall, from Forum Systems. • This web services firewall implements the abstract architecture captured by the Application Firewall pattern. • Then we consider the XACML Access Control Evaluation pattern

12. Application Firewall

13. XACML access control evaluation

14. 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.

15. Comparing standards • To compare two standards, we propose a set of steps, which involve the patterns’ UML class diagrams along with the written elements of a pattern: 1. Compare the problem that they solve. 2. If these problems are similar enough, compare the context in which they solve the problems, in particular, one standard can be more general than the other. 3. If their contexts are similar enough, compare the way they solve the problem, in particular, one can balance their respective advantages and liabilities. 4. Use the class diagrams to find some similar components of the solution, but also some similar architectures between these components.

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

17. XACML Policy Language

18. WS-Policy • Intent • WS-Policy describes a Web service endpoint’s requirements for a client to access its service. • Context • A Web service endpoint invoking another Web service endpoint on behalf of a subject (user, application, …) by sending and possibly receiving SOAP messages. The SOAP messages are protected by the means of the WS-security specification.

19. WS-Policy • Problem • The use of a service is subordinated to some high level requirements (a policy). For example, the user should be authenticated in a certain way, or a quality of service should be met. A Web service may be accessed by clients having no prior knowledge about the service, and thus this latter may not know what types of credentials (security tokens) to send to the service.

20. WS-Policy • Problem • How do you inform the clients of these requirements? The solution to this problem is affected by the following forces: • The clients may be from different technologies and from different organizations. • Therefore they may be able to use only a restricted set of security mechanisms, that would not allow them to meet the requirements.

21. WS-Policy • Solution • Attach to each Web service endpoint a Policy used to control access to it. Propose different sets of required claims for using the service. • In order to achieve this, a Policy is made of several PolicyAlternatives, that the requester can choose from. The requester must satisfy at least one PolicyAlternative to access the service. • A PolicyAlternative is a collection of PolicyAssertions. It corresponds to a set of required claims. A PolicyAssertion is simply an individual requirement. A requester supports a PolicyAlternative if and only if all its PolicyAssertions are satisfied.

22. WS-Policy • Solution

23. WS-Policy • Consequences • This pattern presents the following advantages: • The clients can automatically discover a web services’s policies. • A larger class of clients can be targeted, since several policy alternatives are proposed. • The pattern also has some (possible) liabilities: • The object of the policy (the web service’s operation), as well as the subject of the policy are implicit, and not mentioned within it. • Known Uses • Microsoft’s implementation.

24. 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.

25. 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.

26. 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, …

27. 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.

28. 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.

29. 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.

30. WS-*