secure systems research group - fau a trust model for web services ph.d dissertation progress report...

Secure Systems Research Group - FAU

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 EngineeringFlorida Atlantic University, Boca Raton FL


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


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)


Agenda

• Future work– Formal (Semi-formal?) definition of a model for the

interface between trust model and access control model (Spring 2006 & Summer 2006)

Credential types

Trust level(Resource, action,

context, effect)

Trust policies Access policies

Assigned trust level Required trust

level


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


Using patterns to compare web services security products and

standards


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

Abstract Solutions

Concrete Solutions for Web Services

Authorization

XMLFirewall

XACML Access Control Evaluation

XACML Policy Language

WSPL

ApplicationFirewall

Reverse Proxy

Multiple Agents

extends

isConfiguredAs isConfiguredAs

enforces

implements

extends

implements

enforces

defines

implements

WS-Security

WS-Policy

implements

definesReference

Monitor

enforces

implements

enforces

enforces


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


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

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


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


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.


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.


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.


WS-Policy

• Solution

Policy

PolicyAlternative

*

+processSOAPMessage()

-URI

WebServiceEndPoint

1

PolicyAssertion

*

-sender *

-receiver *

sendsMessageTo


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.


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.


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.


WS-*

SecurityTokenService

Policy

PolicyAlternative

*

+processSOAPMessage()

-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

secure systems research group - fau a trust model for web services ph.d dissertation progress report...

Documents

web services security

ws security standards

web serviceswill

web services firewalls

web services composition

web servicesph

catalog of security

unified trust model