Transcript Using patterns to understand and compare web services security

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 Engineering
Florida Atlantic University, Boca Raton FL
Secure Systems Research Group - FAU
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
Secure Systems Research Group - FAU
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)
Secure Systems Research Group - FAU
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
Assigned trust
level
Trust policies
Secure Systems Research Group - FAU
(Resource, action,
context, effect)
Required trust
level
Access policies
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
Secure Systems Research Group - FAU
Using patterns to compare web
services security products and
standards
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
Web services security patterns
Reference
Monitor
enforces
defines
defines
implements
Abstract Solutions
extends
XML
Firewall
implements
implements
Concrete Solutions for
Web Services
Authorization
Application
Firewall
enforces
enforces
enforces
XACML Access
Control Evaluation
WS-Policy
XACML Policy
Language
enforces
isConfiguredAs
Reverse
Proxy
WS-Security
isConfiguredAs
Multiple
Agents
implements
implements
Secure Systems Research Group - FAU
extends
WSPL
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
Secure Systems Research Group - FAU
Application
Firewall
Secure Systems Research Group - FAU
Resource
-attributeValues
*
*
isAuthorizedFor
Subject
-attributeValues
*
*
requestsAccess
PolicyEnforcementPoint
1
1
XACMLAccessRequest
XACMLAccessResponse
-decision={Permit,Deny,Indeterminate,NotApplicable}
-obligations
-subjectAttributes
-resourceAttributes
-action
-environmentAttributes
ContextHandler
*
1
correspondsTo
PolicyInformationPoint
*
correspondsTo
XACML
access
control
evaluation
1
1
PolicyDecisionPoint
ApplicablePolicySet
evaluates -policyCombiningAlgorithm
*
+retrieveApplicablePolicy()
+evaluateApplicablePolicy()
PolicyComponent
*
1
*
PolicyAdministrationPoint
<<creates>>
Secure Systems Research Group - FAU
+getAttributeValue()
correspondsTo
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
Comparing standards
• We choose a pair of standards to
compare, we consider XACML Policy
Language against WS-Policy.
Secure Systems Research Group - FAU
PolicyComponent
-obligation
Action
XACML
Policy
Language
PolicySet
Policy
+policyCombiningAlgorithm()
+ruleCombiningAlgorithm()
*
*
Resource
*
1..*
-attributes
1
*
Rule
Target
Subject
-effect={Permit,Deny}
-condition
-attributes
1
1
*
Environment
*
-attributes
PolicyAdministrationPoint
+addRule()
+deleteRule()
+updateRule()
+createPolicy()
+deletePolicy()
+createPolicySet()
+deletePolicySet()
Secure Systems Research Group - FAU
*
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
WS-Policy
-sender
• Solution
sendsMessageTo
*
WebServiceEndPoint
-URI
+processSOAPMessage()
1
-receiver
Policy
*
PolicyAlternative
*
PolicyAssertion
Secure Systems Research Group - FAU
*
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
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, …
Secure Systems Research Group - FAU
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 WSPolicy 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.
Secure Systems
- FAU
Research Group
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.
Secure Systems Research Group - FAU
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.
Secure Systems Research Group - FAU
Security
TokenService
WS-Trust
WS-Security
sendsMessageTo
-sender
WS-Policy
*
SOAPMessage
WebServiceEndPoint
-URI
+processSOAPMessage()
1
*
-receiver
*
*
*
*
Policy
SecurityToken
requires
*
*
PolicyAlternative
WS-*
Signed
SecurityToken
*
*
*
*
PolicyAssertion
Claim
1
correspondsTo
proves
1
*
Subject
correspondsTo
1
Confidentiality
Assertion
SecurityToken
Assertion
Integrity
Assertion
MessageAge
Assertion
SecurityHeader
Assertion
Visibility
Assertion
WS-SecurityPolicy
Secure Systems Research Group - FAU
XMLEncryption
XMLDigital
Signature