Transcript Policy Assertion - Secure Systems Research Group

Florida Atlantic University
Department of Computer and Electrical Engineering
&Computer Science ( CEECS )
Secure Systems Research Group
Fall 2009
“A Pattern for the WS-Policy Standard”
Ola Ajaj
[email protected]
1
Introduction
• Web Services Standards can be :
•Lengthy documents.
•Too many details.
•Difficult for vendors to develop products.
•Difficult for users to decide what product to use.
• Also, several organizations that have different goals have developed
standards that may overlap and even conflict to each other.
• We develop patterns for these standards to have a better understanding.
Security Standards
WS- SecureConversation
WS-Federation
WS-Policy
WS-Trust
WS-Authorization
WS-Privacy
XKMS
SAML
XACML
SPML
WS-Security
SOAP Foundation
XML
Encryption
XML
Digital
Signature
3
WS-Secure Conversation
WS-Federation
WS-Trust
WS-Policy
WS-Security
XACML
XML
Encryption
Symmetric
Encryption
Asymmetric
Encryption
XML
Signature
Digital Signature
With Hashing
4
Introduction
Ajiad is a travel agency that has expands its office services to cover the online
trade customers. Ajiad offered many of its everyday operations to a web
services-based system, some of which have a certain level of privacy and
security for the customers who have been granted privileges.
Ajiad now declared new rules for defining the way its web services should
accessed by means of policies in terms of who, when and in what they can be
used.
5
WS-Policy
 Why?
 To integrate software systems with web services.
 What?
 Provides a flexible and extensible grammar for expressing the
capabilities, requirements, and general characteristics of Web Service
entities
 How?
 Defines a model to express these properties as policies
 Without this standard, developers need docs.
6
WS-Policy Model
WSDl
FindService
PublishService
CreatePurchaseOrderRequest
CreatePurchaseOrderResponse
Consumer
SOAP/HTTP
Create
Purchase
Order
Provider
7
Terminology
 Policy: a collection of policy alternatives.
 Policy alternative a collection of policy assertions.
 Policy Assertion: represents a requirement, a constraint, a capability of
the behavior of a web service.
** An assertion is a declaration of certain facts, such as “Jad was granted update privileges to database X at time Y”.
** A behavior for example could be guarantee of message delivery.
 Policy Expression: set of one or more policy assertions that combined to
do some wrok.
8
WS-Policy Model
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<Assertion> ...
...
<Assertion> ...
</wsp:All>
...
<wsp:All>
<Assertion> ...
...
<Assertion> ...
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</Assertion>
Policy Expression
Collection of alternatives
(„pick one“)
</Assertion>
Policy Alternative
Collection of assertions
(„do all“)
</Assertion>
Policy Assertion
Domain-specific behavior
</Assertion>
Policy Normal Form
9
Terminology
 Policy Attachment:
the mechanism for associating policy expressions with one or
more subjects.
10
A Pattern for WS-Policy
• Intent
Without a clear definition of how to use web services,
they could be chaotic.
Policy Framework defines a base set of constructs that
checks the requests made by requestors in order to
verify that they are fulfilling their assertions and
convey their conditions before interacting with the
web service.
11
Example
While transforming to its new system, some of Ajiad’s Travel Agency
customers have been accessing web services they are not allowed to do.
The reason for that was having outdated and unreliable services (due to a
decreased number of customers or violating security rules) and losing
money (due to accessing services that in some point requires fees and
subscription).
12
Context
Distributed applications need to communicate in a
collaborative way to perform some work in a webservice environment. For this, they use the internet
(unreliable and insecure environment)which is
explored to the attackers.
13
Problem
Without applying relevant policies for protection,
web services have no means to assure reliability and
security in their integration.
14
Forces
• The possible solution is constrained by the following forces:
– Confidentiality and Information Disclosure Malicious consumers may try to
read and modify sensitive information. We need to define appropriate policies
to protect the information.
– Tampering Malicious users try to tamper or replace policy assertions.
– Reception and Repudiation The provider may perform a malicious activity that
is not expected by the requestor.
15
Forces
- Regression A policy may offer several alternatives that vary from weak to
strong requirements. An adversary may interfere and discard this policy
and insert a weaker policy previously issued by the same provider.
- Denial of Service Malicious providers may provide a policy expression with
a large number of alternatives, a large number of assertions in
alternatives, deeply nested policy expressions or chains of Policy
Reference elements (e.g. Internet addresses) that expand exponentially.
16
Solution
– Each policy is defined in terms of nested constructs that conveys the
restrictions the policy implies. When the policy is attached to a web service,
clients looking to transact with that web service are forced to follow its
assertions (e.g. signing, encryption, timestamp, and username) of the type
specified in the policy.
– Web services are protected against unauthorized access by having policies that
provide conditions in order to use them. Requesters willing to use web service
are required to follow its policy first.
17
NormalForm
1
associateWith
CompactForm
PolicyAttachment
attach
0..*
+attachPolicy()
1
PolicyScope
*
-attributes
Policy
Form
convey
expressedAs
-name
-ID
-reference
+addAlternative()
+deleteAlternative()
+updateAlternative()
+assignReference()
1
PolicyExpression
1
0..*
*
PolicySubject
-attibutes
A PolicyOperator
could be used to group
Assertions into Alternatives
1
-reference
-digest
1
0..*
0..*
Entity
0..*
PolicyAlternative
{PolicyExpression
should not reference
itself directly or indirectly}
+addAssertion()
+deleteAssertion()
+updateAssertion()
1
PolicyAssertionParameter
1
0..*
*
-child
-element
PolicyAssertion
contains -attributes
-children
+addAsertion()
0..*
+deletAssertion()
+updateAssertion()
1
1
PolicyAssertionType
0..*
-nameSpace
-localName
0..*
Requirement
18
Dynamics
We describe the dynamic aspects of the WS-Policy
using sequence diagrams for the use cases “create a
policy” and “request a service”.
– Create a new policy:
• Summary: A provider will create a new policy for a web
service.
• Actors: policy provider.
• Precondition: The provider has already created a web
service.
19
Create a new policy
:Provider
:WebService
<<createPolicy>>
:Policy
addAlternative
addAssertion
addRequirement
policyCreated
embedPolicy
addPolicy
policyEmbedded
20
Create a new policy
– Description:
• The policy provider will create the policy by specifying and adding its required
alternatives, assertions and requirements. The provider creates as many assertions as
necessary to meet the conditions for his/her Web Service.
• All the alternatives, assertions and requirements are added to the web service.
• The provider embeds the policy to the web service.
• The Web Service adds the policy to its structure.
– Postcondition: The provider has attached the policy to
its designated web service.
21
Request a service
•
Note: this use case Need to be revised
• Request a service:
– Summary: A requester will use a published policyembedded web service.
– Actors: policy Provider, policy Requestor and Broker.
– Precondition: The provider had already created a web
service with a policy that controls its services.
22
Request a service
:Provider
:Broker
:Requester
<<createWebService>>
:WebService
webServiceCreated
embedPolicy
addPolicy
policyEmbedded
publishWebService
addWebService
webServicePublished
webServiceDiscover
webServiceResult
webServiceRequest
webServiceResponce
23
Request a service
– Description:
» The policy Provider will publish its web service to Broker.
» The Broker will add the web service to its registry or repository.
» The Requestor contacts the Broker to find the suitable web service and
the Broker will replay with results to choose from.
» The Requester will send a UseServiceRequest to the Provider who in
turns replayed with a UseServiceResponce.
– Postcondition: The Requestor now is using the Web
Service in terms of satisfying its policy conditions.
24
Implementation
– In order to assure effective implementation, we need to take in
consideration the following:
• A policy may or may not reference another policy (ies) depending
on the level of authentication that is required.
• A policy alternative may contain multiple assertions of the same
type. Policy assertions within a policy alternative are not ordered.
However, providers can write assertions that control the order in
which behaviors are applied.
25
Implementation
• Policy Assertions are the main blocks of the policy that specify a particular
behavior. Translating these assertions will qualify the behavior indicated
by. For example, sp:AsymmetricBinding assertion is identified to support a
specific reliable messaging mechanism, while sp:SignedParts assertion is
used to indicate message-level security and sp:EncryptedParts assertion is
used to indicate the parts of a message that require confidentiality.
• A policy expression conveys policy in an interoperable form, either in a
normal form (which is the most straightforward XML representation of the
policy data model) or in an equivalent compact form (that is used to
compactly express a policy with more description about definitions and
outlines).
• A policy Expression should not reference it self directly or indirectly to
avoid the forces mentioned under Problem section above.
26
Example Resolved
– Ajiad’s new web-based system now has more control over its services by
applying prerequisite conditions and security constrains through policies. So, in
order to use any service, all customers are required to compel with its policy
conditions and agree with its terms before using that web service.
– Ajiad’s strategy of giving customers relevant privileges (compatible with their
memberships) are still valid, but this time with enhanced categories that
prioritize their services and protect business credentials.
27
Consequences
– (+) Policy providers can use mechanisms from other web services specifications such as
WS-Security [ibm09b], XML Digital Signature [w3c08] and WS-Metadata Exchange
[w3c09] and that’s by securing access to the policy, requiring authentication for sensitive
information and omitting sensitive information from the policy.
– (+) Requestors should discard a policy unless it is signed by the provider and presented
with sufficient credentials.
– Policy providers can avoid older or weaker policy alternatives.
– (+) Requestors can discard policy alternatives which include assertions whose behavior
cannot be verified by examining the wire message from the provider to requestor.
– (+) Policy should use a modal margin with defaults on number of policy alternatives,
number of assertions in an alternative, depth of nested policy expressions.
– (-) WS-Policy is an immature specification which is still changing.
28
Related Patterns
• A pattern language for security models. [Fer01]
• Rule Object 2001: A Pattern Language for Adaptive and Scalable Business
Rule Construction. [Ars01]
• Patterns for the eXtensible Access Control Markup Language. [Del05]
• Patterns for Access Control in Distributed Systems. [Del07]
29