Secure Systems Research Group - FAU Using patterns to compare web services standards E. Fernandez and N. Delessy

Secure Systems Research Group - FAU

Using patterns to compare web services standards

E. Fernandez and N. Delessy


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.


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.


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.


Web services security patterns

Generic Solutions

Concrete Solutions

Authorization

XMLFirewall

XACML Access Control Evaluation

XACML Policy Language

WSPL

ApplicationFirewall

Reverse Proxy

Multiple Agents

extends

isConfigured isConfigured

uses

uses

extends

implements

enforcesdefines

uses

WS-Security

WS-Policy

enforces

defines

Reference Monitor

enforces

implements

enforces


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


Application Firewall


PolicyAdministrationPoint

+retrieveApplicablePolicy()+evaluateApplicablePolicy()

-policyCombiningAlgorithm

PolicyDecisionPoint

PolicyEnforcementPoint

evaluates

PolicyComponent

ApplicablePolicySet

ContextHandler

1

*

correspondsTo +getAttributeValue()

PolicyInformationPoint

-attributeValues

Subject

-attributeValues

Resource

1

*

11

*

-decision={Permit,Deny,Indeterminate,NotApplicable}-obligations

XACMLAccessResponse

* *

1

1

correspondsTo

*

*

<<creates>>

requestsAccess

-subjectAttributes-resourceAttributes-action-environmentAttributes

XACMLAccessRequest

* *isAuthorizedFor

correspondsTo

XACML access control

evaluation


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.


Comparing standards

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


XACML Policy

Language

+policyCombiningAlgorithm()

PolicySet

+ruleCombiningAlgorithm()

Policy

-effect={Permit,Deny}-condition

Rule

1

Target

-attributes

Resource

-attributes

Subject

Action

-attributes

Environment

*

*

*

*

+addRule()+deleteRule()+updateRule()+createPolicy()+deletePolicy()+createPolicySet()+deletePolicySet()

PolicyAdministrationPoint

1 *

-obligation

PolicyComponent

1..*

* *1


WS-PolicyPolicy

PolicyAlternative

*

+processSOAPMessage()

-URI

WebServiceEndPoint

1

PolicyAssertion

*

-sender *

-receiver *

sendsMessageTo


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.


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.


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


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.


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.


WS-Security


-URI

WebServiceEndPoint

Subject

SecurityToken

Claim

SOAPMessage

*

1proves

XMLEncryption XMLDigitalSignature

* * *

-sender *

-receiver *

sendsMessageTo

*

*

requires

*

1

correspondsTo

*

1correspondsTo

SignedSecurityToken

*


WS-*

SecurityTokenService

Policy

PolicyAlternative

*


-URI

WebServiceEndPoint

Subject

SecurityToken

Claim

SOAPMessage

*

1proves

XMLEncryption XMLDigitalSignature

* * *

-sender *

-receiver *

sendsMessageTo

*

*

requires

*

1

correspondsTo

*

1correspondsTo

SignedSecurityToken

*

1

PolicyAssertion

*

WS-Security

WS-Policy

SecurityTokenAssertion

IntegrityAssertion

ConfidentialityAssertion

VisibilityAssertion

SecurityHeaderAssertion

MessageAgeAssertion

WS-SecurityPolicy

WS-Trust


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.

Documents

Secure Systems Research Group - FAU Using patterns to compare web services standards E. Fernandez and N. Delessy