Secure Systems Research Group - FAU 1 A Trust Model for Web Services Ph.D Dissertation Progess Report Candidate: Nelly A. Delessy, Advisor: Dr E.B. Fernandez.

Secure Systems Research Group - FAU 1

A Trust Model for Web Services

Ph.D Dissertation Progess 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 model 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

• Existing Web services Access Control Models:– Patterns for XACML

• Future work– Patterns for the WS-* Family– Comparison


Web services Access Control Models: Patterns for XACML

• The eXtensible Access Control Markup Language (XACML) has been defined by OASIS

• includes a policy and an access decision language.

• They define ways to express authorization rules and to enforce these rules

• The XACML profile for web services, also known as WSPL (Web Services Policy Language), is a language to declare authorization rules for protecting web services endpoints.

• We describe three patterns :– XACML Policy Language – XACML Access Control Evaluation – WSPL


XACML Policy Language

• XACML enables an organization to represent authorization rules in a standard manner.

• Context:– A complex environment such as a large enterprise with

many partners, contractors…

• Problem:– Resources are usually from various types and the

enforcement mechanisms come in various forms – policies are implemented in many locations, using

different syntaxes – Security policies in an organization are typically issued

by different actors and and the policies they write may concern a wide and overlapping set of resources

Defining these policies may be complex, and thus error prone.



• Problem:– How do we unify the definition of access policies

throughout the organization, making the whole system simpler and less error-prone?

• Forces:– Policies may be expressed in different forms– Policies are constantly changing and they need to be

constantly updated– An active entity accessing a resource can be

represented in a variety of ways– Some policies can require a set of actions (or

obligations) to be performed in conjunction with policy enforcement (auditing, notification…)

– The environment in which the access is requested can also affect an access decision. For instance, an access may only be permitted at some hours of the day



• Solution:– Write all policies in a common language using

a standard format. – This format is generic enough to implement

some common high level policies or models (open/closed systems, extended access matrix, RBAC, multilevel).

– In addition, define a way to compose policies so that when several policies apply to one access, it is possible to render one unique decision. The policies are defined with an embedded combining algorithm.


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



• Dynamics: Create a new policy

createRule1

addRule1

createRule2

addRule2

createPolicy

<<actor>>:PolicyWriter

:PolicyAdministrationPoint

rule1:Rule

rule2:Rule

<<create>>

<<create>>

:Policy<<create>>

addRule1

addRule2

addObligations

addTarget

addRuleCombiningAlgorithm

policyCreated

ruleCreated

ruleCreated



• Implementation:1. Define semantics for the subject, the

resource and the environment’s attributes.

2. Translate existing rules in the XACML format.

3. Define new rules and implement them as XACML rules and policies.

4. Add/Remove policies when needed.



• Consequences:– The organization’s policies to control access are easily

defined using he constructs of the language. This makes the whole system less complex, and thus more secure.

– A variety of policy types can be described, as the policy language includes the resource, the subject and the environment’ attributes. Moreover, these attributes can be from existing standards (LDAP attributes, SAML, …), and are extensible.

– Similarly, a variety of subject types can be described.– Policies and rules can be easily combined.– A policy writer can specify complex conditions.– This pattern enables logging or other actions through

the obligation concept



• Known Uses:– This pattern is used in several commercial

products:• Xtradyne's WS-DBC (an XML Firewall),• DataPower's XS40 XML Security Gateway• Parthenon Computing has produced a suite of

Policy products based on XACML (Policy Tester, Policy Engine, Policy Server)

• Sun provides an open source implementation written in Java



• Related Patterns:– The policies are structured according the

Composite Pattern [Gam95].– The Role-Based Access Control pattern, a

specialization of the authorization pattern, is applicable if the policies’ subjects attributes are defined in terms of roles [Fer01].


XACML Access Control Evaluation

• XACML defines a standard request/response syntax for access control decisions.

• Context:– A complex environment such as a large enterprise with

many partners, contractors…– These various actors are accessing the organization’s

resources– These accesses are controlled at several enforcement

points, according to security policies.

• Problem:– Resources are usually from various types and the

enforcement mechanisms come in various forms the organization has to write and maintain numerous authorization systems for its networks

– How do we enforce the rules defined in the institution policies?



• Forces:– Enforcement points could be implemented in a variety

of technologies (part of a Web Server, WAN, …). – Any type of security policy should be enforced.

• Solution:– Protect each resource by a PolicyEnforcementPoint.– All access requests are submitted to a unique

PolicyDecisionPoint in a common format.– This PolicyDecisionPoint returns the access decision,

based on the ApplicablePolicy corresponding to the access’s context.


XACML Access Control

Evaluation

PolicyAdministrationPoint

-policyCombiningAlgorithm

PolicyDecisionPoint

PolicyEnforcementPoint

renders

PolicyComponent

ApplicablePolicySet

locates

1 1..*

enforces

-subjectAttributes-resourceAttributes-action-environmentAttributes

XACMLAccessRequest

*

*

producesappliesTo

1*evaluates

ContextHandler

1 *

accesses

+getAttributeValue()

PolicyInformationPoint

-attributeValues

Subject

-attributeValues

Resource

-attributeValues

Environment

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

XACMLAccessResponse

accesses

in

1

*

11

accesses

*


XACML Access Control Evaluation• Dynamics: Controlling an access request for a resource


:PolicyComponent

:PolicyComponent

<<actor>>:Subject

:PolicyEnforcement

Point

:ContextHandler

:PolicyDecision

Point

:PolicyAdministration

Point

:PolicyInformation

Point:Resource

requestAccess( subjectAttributeValues,

action,resourceId) requestAccess( subjectAttributeValues,

action,resourceId)

getResourceAttributes()

getEnvironmentAttributes()

XACMLAccessRequest( subjectAttributeValues,

resourceAttributeValues,action,

environmentAttributeValues)

retrieveApplicablePolicy()

ApplicablePolicy

:PolicyComponent

evaluateTarget()

targetMatches

addToApplicablePolicy()

evaluateApplicablePolicy()

requestAdditionalAttributes()

requestAdditionalAttributes()

additionalAttributes

additionalAttributes

evaluateApplicablePolicy()

XACMLAccessResponse

accessGranted

fulfillObligations()

accessResource



• Implementation:1. Implement a ContextHandler for applications

that already have a PolicyEnforcementPoint that use another access decision language

2. Implement an XACML PolicyEnforcementPoint for those applications that do not implement access control

3. Add the translated existing authorization rules to the PolicyAdministrationPoint

4. Add the new authorization rules to the PolicyAdministrationPoint



• Consequences:– Advantages:

• Since the access decisions are requested in a standard format, an access decision becomes independent from its enforcement. A broad variety of enforcement mechanisms could be supported and can evolve separately from the PolicyDecisionPoint.

• This pattern can support the access matrix, RBAC, multilevel models.

– (possible) liabilities:• It is intrusive for existing applications that already have

security, since they require the implementation of a ContextHandler.

• It could affect the performance of the protected system as XML is a verbose language.



• Related Patterns:– The Authorization pattern [Fer01] defines the

security model for this pattern.– It can also implement the Metadata-based

Access control Model [Pri04]. – The Application Firewall pattern [Del04] could

be implemented according to the XACML patterns.

– The PolicyEnforcementPoint is a special case of a Reference Monitor [Fer01].



• Related Patterns:

XML Firewall

Multiple Agent Reverse Proxy

XACML Policy

Language

WSPL

Generic Solution

Concrete Solutions

Authorization

Application FirewallXACML Access

Control Evaluation

enforcesimplements defines

extends

uses

uses

extends

is configured is configured

uses


WSPL

• WSPL enables an organization to represent access control policies to its web services in a standard manner and a web services consumer to express its requirements in a standard manner.

• Context:– Web services endpoints invoking each other.– Providers have security policies to control

access to their web services,– consumers have requirements for a web

service invocation


WSPL

• Problem:– Web services are self-describing through

WSDL and can be automatically discovered using UDDI using various syntaxes for their policy description would reduce these two properties of a web service.

– security policies are typically issued by different actors from its departments and the policies they write may concern a wide and overlapping set of web services.

– How do we describe policies to control web services invocations?


WSPL

• Solution:– Write web services policies in the XACML

language: Bind each WSDL web service component to an XACML component. Besides, define combination rules for such policies.


WSPL

-parameters-technicalFeatures

Aspect

WebService

Attribute

AuthorizedAttribute

EndPointPolicy

Predicate

-parameterValues-technicalFeatures

Strategy

Objective

ConstrainedAttribute

Endpoint

1

1

*

1

1..*

-target

PolicySet

1 1

defines

1 1

1 1

governs

1

*[ordered]

Policy

1..*

1 1

defines

1

*

Rule

UnconstrainedAttribute

XACML

WSDL

correspondsTo

1

*

1 1

defines

*

* *

constraints

Operation

Message

1

1

OperationPolicy

MessagePolicy

1 1

1 1

correspondsTo

correspondsTo

1

1

1

1

defines

defines

1

1..*

1

1..*

1

*

1

*

1

*

1

*

satisfies

Combiner

*

*

combines


WSPL

• Consequences:– Advantage:

• Consumers and Providers ‘s policies can be combined to decide how a service invocation should occur.

– (possible) liabilities:• It is intrusive for existing web services that

already implement security, since their require the implementation of a ContextHandler.

• It could affect the performance of the protected system as XML is a verbose language.


WSPL

• Known Uses:– OpenWSPL is an open source implementation

of the Web-Service Policy language, written in Java

• Related Patterns:– This pattern is a specialization of the XACML

Policy Language pattern. It can implement the Metadata-based Access control Model [Pri04].

– The XML firewall [Del04] could be implemented using this pattern.


Future work:

Patterns for the WS-*

Family

WSEndpoint

**

accesses Policy

PolicyAlternative

PolicyAssertion

0..*

0..*

PolicyVocabulary

PolicyAssertionType

* 1

has

0..*

1

*

*

1

has

has

*+requester*

supports

+requester

*

-policyAlternative

1supports

PolicyExpression

represents

PolicyScope

PolicyAttachment

PolicySubject

ex: endpoint, message, resource, interaction ???

A requester supportsa PolicyAlternative iff allits PolicyAssertions aresupported by the requester.

A requester supportsa Policy if at least one ofits PolicyAlternatives aresupported by the requester.

PolicyOperator

0..*

WS-Policy

1 .. *

SecurityTokenReference

SecurityToken

SignedSecurityToken UnsignedSecurityToken

Kerberos ticket,X.509 certificate..

password, SAML Assertion...

Claim

DigitalSignature

1..*

0..1

*

*

XML Digital Signature

SecurityTokenAssertionWS-Security

IntegrityAssertion

ConfidentialityAssertion

VisibilityAssertion

SecurityHeaderAssertion

MessageAgeAssertion

TextEncodingAssertion

LanguageAssertion

SpecVersionAssertion

MessagePredicateAssertion

WS-SecurityPolicy

WS-PolicyAssertions

Secure Systems Research Group - FAU 1 A Trust Model for Web Services Ph.D Dissertation Progess Report Candidate: Nelly A. Delessy, Advisor: Dr E.B. Fernandez.

Documents

trust policies

definition of access

access decision language

xacml policy language

xacml policy language

different forms policies

various forms policies

web services ph