Transcript Using patterns to compare web services standards

Using patterns to compare web
services standards
E. Fernandez and N. Delessy
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
Authorization
defines
implements
Generic Solutions
implements
Concrete Solutions
Application
Firewall
extends
XML
Firewall
enforces
uses
defines
enforces
XACML Access
Control Evaluation
WS-Policy
XACML Policy
Language
enforces
isConfigured
Reverse
Proxy
WS-Security
isConfigured
Multiple
Agents
uses
uses
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)
• here the Application Firewall pattern and
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
• 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
*
-sender
sendsMessageTo
*
WebServiceEndPoint
-URI
+processSOAPMessage()
1
WS-Policy
-receiver
Policy
*
PolicyAlternative
*
PolicyAssertion
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
sendsMessageTo
-sender
*
SOAPMessage
WebServiceEndPoint
-URI
+processSOAPMessage()
*
-receiver
*
*
*
SecurityToken
WSSecurity
XMLEncryption
requires
*
Signed
SecurityToken
*
*
*
1
Claim
proves
correspondsTo
1
*
Subject
correspondsTo
1
Secure Systems Research Group - FAU
*
XMLDigital
Signature
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
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