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

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

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

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.