A Trust Model for Web Services Ph.D Dissertation Progress Report Candidate: Nelly A. Delessy, Advisor: Dr E.B. Fernandez Department of Computer Science and Engineering Florida Atlantic University, Boca Raton FL

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

• Dissertations 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
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 endpoints
  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
  servicess 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 services
  operation), as well as the subject of the policy
  are implicit, and not mentioned within it.
• Known Uses
• Microsofts 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
  organizations Reference Monitor to control
  access to an organizations 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
  services 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 environments
  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 environments
  attributes in XACML.
• Also, the security token defined in WS-Security
  can correspond to a users attribute.

28
Comparison

• However, minor dissimilarities exist between
  these two standards in terms of
• Attributes/assertion operators WSPL allows a
  wide range of comparisonswhereas 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-