Security for Web Services and
Service Oriented Architectures
Bhavani Thuraisingham
The University of Texas at Dallas
June 2013
Acknowledgement

Professors Elisa Bertino and Lorenzo Martino;
Purdue University for much of the information
and charts on web services security standards
and digital identity management



bertino@cs.purdue.edu
lmartino@purdue.edu
Others:



Dr. Frederica Pacci; University of Milan for ideas obtianed when
serving on her thesis committee on reserach in web services
security
Prof. I-Ling Yen and Wei-She; University of Texas at Dallas for
collaboration on web services security and the delegation model
Book by Thomas Erl on Service Oriented Architectures, Prentice
Hall, 2005
2
Objective and Scope



The objective of this course is to provide an overview of
the significant developments in SOA and Web Services
Security Standards as well as directions for future
developments
Current work on SOA security is focusing mainly on
access control as well as confidentiality and integrity.
Solutions proposed for systems to address intrusion
detection, denial of service and infrastructure attacks,
insider threat analysis including data mining
techniques for security applications are beyond the
scope of this course.
3
Outline



SOA and Web services: Overview
SOA and Web services security: Overview
WS-Security and WS-* Security
4
Service Oriented Architecture
(SOA)
http://en.wikipedia.org/wiki/Service-oriented_architecture








Service Oriented Architecture (SOA) is an architectural style that guides all
aspects of creating and using business processes, packaged as services,
throughout their lifecycle, as well as defining and provisioning the IT
infrastructure that allows different applications to exchange data and participate
in business processes loosely coupled from the operating systems and
programming languages underlying those applications
SOA represents a model in which functionality is decomposed into distinct units
(services), which can be distributed over a network and can be combined
together and reused to create business applications
These services communicate with each other by passing data from one service
to another, or by coordinating an activity between two or more services.
SOA concepts makes software development flexible and extensible
Service oriented analysis is becoming key to modeling and analyzing software
The concepts of Service Oriented Architecture are often seen as built upon, and
the evolution of, the older concepts of distributed computing and modular
programming
While object-orientation views the world as a collection of objects, service
orientation views the world as a collection of services
SOA is technology independent; however it is commonly realized using web
services
5
Web service definition
“A Web Service is a software system designed to
support interoperable machine-to-machine
interaction over a network. It has an interface
described in a machine-processable format
(specifically WSDL). Other systems interact with the
Web service in a manner prescribed by its
description using SOAP messages, typically
conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards.”
Source: http://www.w3.org/TR/ws-arch/
6
SOA
Publish Services
Query
UDDI
Answer
Request
Service
requestor Response
Service
providers
7
Web Services (WS) Framework









An abstract (vendor neutral) existence defined by standards organizations
and implemented by (proprietary) technology platforms
Core building blocks that include web sercices, service descriptions and
messages
A communication agreement centered around service descriptions and
WSDL
A messaging framework comprised of SOAP technology concepts
A service description registration and discovery architecture sometimes
realized through UDDI
A well defined architecture that supports messaging patterns and
compositions
A second generation of web services extensions (also known as WS-*
specifications) continually broadening its underlying feature-set
Concepts in WS-* include: Message Exchange Patterns (MEP), Service
Activity, Coordination, Atomic Transaction, Business Activities,
Orchestration (WS-BPEL), Choreography (WS-CDL)
Reference: Service Oriented Architecture, Thomas Erl, Prentice Hall, 2005
8
Standardization bodies related
to Web Services
9
SOA Security


Our approach is to implement SOA through web services;
therefore SOA security essentially is about web services
security
Three core specifications




WS-Security, XML-Signature, XML-Encryption
WS*-Security is the second generation of technologies for SOA
security
Single sign-on (SSO) is a form of centralized security
mechanism that complements the WS-Security extensions
Related specifications for SOA security

WS-Security, WS-SecurityPolicy, WS-Trust,
WS-SecureConversation, WS-Federation, XACML, Extensibe Rights
Markup Language, XML Key Management, XML, Signature, SAML,
.NET Passport, Secure Socket Layer, WS-I Basic Security Profile
10
Basic Components of SOA
Security






Identification

For service requestor to acces a secure service provider it must first provide
information that expresses its origin or owner. This is referred to as making a
claim
Authentiaction

A message being delivered to a receipient must prove that the message is in
fact from the sender that it claims
Authorization

Once authenticated, the receipient of a message may need to determine
what the requestor is alowed to do
Singe sign on

It is supported by SAML, .NET Passport and XACML
Confidentiality and Integrity

Confidentiality is concerned with protecting the privacy of the message
content, Integrity ensures that the message has not been altered
Transport level and Message level security

Transport level securiy is provided by SSL (securing HTTP), message level
confidentiality and integrity are provied by XML-Encryption and XMLSignature.
11
Web Services Security:
Requirements and Standards


Securing Web services mainly requires to:

provide facilities for securing the integrity and confidentiality of the
messages and

ensure that the service acts only on requests in messages that
express the claims required by policies
Role of Standards

Providing a Web Services Security Framework that is an integral part
of the Web Services Architecture

The framework is a layered and composable set of standard
specifications
12
WS-* security Standards
framework
Security mgmt.
XKMS
Identity Mgmt.
WS-Trust
WS-federation
Message security
WS Security
WS
SecureConversation
Liberty
SAML
Policy & Access
Control
Reliable Messaging
WS ReliableMessaging
WS-Policy
XACML
SAML
SOAP foundation
XML security
Transport level security
Network level security
XML
Encryption
XML
Signature
SSL/TLS
IPSec
13
WS-* security standards
implementations

Microsoft .NET Framework 2.0 / WSE3.0

WS-Security (OASIS 2004 standard), WS-Policy, WSSecurityPolicy, WS-Trust, WS-SecureConversation and
WS-Addressing

SUN Web Services Interoperability Technology
(WSIT)

IBM WebSphere

Open Software: The Apache Software Foundation
Web Services Project (http://ws.apache.org/)
14
XML Encryption
XML Encryption Syntax and Processing
10 December 2002
Status W3C Recommendation
Core standard
Goals:

provide confidentiality for applications that exchange structured data by

Representing in a standard way digitally encrypted resources

separating encryption information from encrypted data, and
supporting reference mechanisms for addressing encryption
information from encrypted data sections and vice-versa
providing a mechanism for conveying encryption key
information to a recipient
providing for the encryption of a part or totality of an XML
document


15
XML Signature
XML-Signature Syntax and Processing
12 February 2002
Status: W3C Recommendation
Core standard: XML Signature is a building block for many web services security
standards (e.g. XKMS and WS-Security)
Goals:



represent a digital signature as an XML element
Processing rules for creating this XML element
The signed data items can be of different types and
granularity (XML documents, XML Elements, files
containing any type of digital data)
16
Securing SOAP messages
Web Services Security: SOAP Message Security 1.1
(WS-Security 2004)
Status: Approved OASIS Standard Specification 1 February 2006

Goals:



Provide single SOAP message integrity and confidentiality
 Using existing digital signature, encryption, and security token
mechanisms
Provide mechanisms for associating security tokens with message
content (header and body blocks)
Extensibility (i.e. support multiple security token format)
the recipient can trust the content of the message and its sender
Security Token - a representation of security-related information (e.g. X.509
certificate, Kerberos tickets and authenticators, mobile device security tokens
from SIM cards, username, etc.).
Signed Security Token - a security token that contains a set of related claims
(assertions) cryptographically endorsed by an issuer.
Examples: X.509 certificates and Kerberos tickets.
17
What is WS-Security?

WS-Security enhances SOAP messaging to provide
quality of protection through:





These mechanisms can be used to accommodate a wide
variety of security models and encryption technologies.
WS-Security also provides a general-purpose, extensible
mechanism for associating security tokens with
messages:



message integrity,
message confidentiality, and
single message authentication.
No specific type of security token is required
support for multiple security token formats
WS-Security describes how to encode binary security
tokens( X.509 certificates and Kerberos tickets)
18
WS-Policy




Web Services Policy 1.2 - Framework (WS-Policy) W3C
Member Submission 25 April 2006
Status: public draft release for review and evaluation only
Main goal: The WS-Policy and WS-PolicyAttachment aim to
offer mechanisms to represent the capabilities and
requirements of Web services as Policies
Policy view in WS-Policy:



A policy is used to convey conditions on an interaction between two
Web service endpoints.
The provider of a Web service exposes a policy to convey conditions
under which it provides the service.
A requester might use this policy to decide whether or not to use the
service.
19
XACML

eXtensible Access Control Markup Language 2 (XACML)
Version 2.0 OASIS Standard, 1 Feb 2005

Status: approved OASIS Standard within the OASIS Access
12 Control TC.

XACML is a general-purpose access control policy language
for managing access to resources

It describes both a policy language and an access control
decision request/response language

Fine access control grained control

Access control based on subject and object attributes

Consistent with and building upon SAML
20
XACML – Key Aspects









General-purpose authorization policy model and
XML-based specification language
XACML is independent of SAML specification
Triple-based policy syntax: <Object, Subject, Action>
Negative authorization is supported
Input/output to the XACML policy processor is clearly
defined as XACML context data structure
Input data is referred by XACML-specific attribute
designator as well as XPath expression
Extension points: function, identifier, data type, rulecombining algorithm, policy-combining algorithm, etc.
A policy consists of multiple rules
A set of policies is combined by a higher level policy
(PolicySet element)
21
XACML data flow model
Source:
oasis-access_control-xacml-2.0-core-spec-os
22
XACML Protocol
Policy
Enforcement
Point (PEP)
XACML
Request/
Response
Policy
Decision
Point (PDP)
Policy
Information
Point (PIP)
Policy
Access
Point (PAP)
23
XACML Protocol






When a client makes a resource request upon a server, the PEP is charged
with AC
In order to enforce AC policies, the PEP will formalize the attributes
describing the requester at the PIP and delegate the authorization decision
to the PDP
Applicable policies are located in a policy store, managed by the PAP, and
evaluated at the PDP, which then returns the authorization decision
Using this information, the PEP can deliver the appropriate response to the
client
XACML Request

Subject

Object

Action
XACML Response

Permit

Permit with Obligations

Deny

NotApplicable (the PDP cannot locate a policy whose target matches
the required resource)

Indeterminate (an error occurred or some required value was missing)
24
XACML Protocol
The Policy Administration Point (PAP) creates
security policies and stores these policies in the
appropriate repository.
2.
The Policy Enforcement Point (PEP) performs
access control by making decision requests and
enforcing authorization decisions.
3.
The Policy Information Point (PIP) serves as the
source of attribute values, or the data required for
policy evaluation.
4.
The Policy Decision Point (PDP) evaluates the
applicable policy and renders an authorization
decision.
Note: The PEP and PDP might both be contained within
the same application, or might be distributed across
different servers
1.
25
XACML policy

A Policy has four main components:






The Rule is the elementary unit of a policy
Main components of a rule:




A target
A rule-combining algorithm identifier
A set of rules
Obligations
A target
An effect: permit or deny
A condition
Policy Language

A policy target specifies a set of:





Resources
Subjects
Actions
Environment
to which it applies
26
Security Assertion Markup
Language (SAML)



Developed by the OASIS XML-Based Security Services
Technical Committee (SSTC)
Status: SAML V2.0 OASIS Standard specification set was
approved on 15 March 2005
Main goal: authentication and authorization


promote interoperability between disparate authentication and
authorization systems
How:


defining an XML-based framework for communicating security and
identity information (e.g., authentication, entitlements, and attribute)
between computing entities
using available different security infrastructures (e.g., PKI, Kerberos,
LDAP, etc)
27
SAML basic concepts

Assertions: The core concept

SAML Authority: a system entity that makes SAML
assertions (also called Identity Provider – IdP – and
Asserting Party)

Service Provider: a system entity making use of SAML
assertions

Relying Party: a system entity that uses received assertions
(named also SAML requester)

SAML Bindings: Bindings describe exactly how the SAML
protocol maps onto the transport protocols.
28
SAML assertions

An assertion is constituted by one or more
statements made by
a SAML
authority
“Martino
authenticated
with
a password at 9:00am”

Different kinds of assertion statement that can be
created by a SAML authority:



“Billsubject
is an account
Authentication: The specified
wasmanager
authenticated
with a $1000
spending limit
by a particular means at a particular
time.
per one-day travel”
Attribute: The specified subject is associated with the
supplied attributes.
Authorization decision statements: the specified
subject is entitled to do a specified action
“John Doe” is
permitted to buy
a specified item
29
SAML entities
SAML Authority
makes SAML assertions
SAML Requester
a system entity that uses
received assertions
Service Providers a
system entity making use of
SAML assertions
30
SAML and XACML
Source: Security Assertion Markup Language (SAML) V2.0 Technical
Overview Working Draft 08, 12 September 2005
31
SAML & Federated Identity


SAML addresses one key aspect of identity
management: how identity information can be
communicated from one domain to another
SAML 2.0 will be the basis on which Liberty
Alliance builds additional federated identity
applications (such as web service-enabled
permissions-based attribute sharing).
32
Summary Points





SOA concept based on service orientation is now a
significant method for software development and promotes
extensibility and flexibility; Service oriented analysis has now
become a standard way to model software
Web Services is just one way to realize SOA
Security for SOA is crucial as SOA is being used in
numerous sectors; since web services realize SOA, web
services security is critical
SOA and SOA Security Standards are being developed by
W3C and OASIS; WS-Security, WS*-Security Framework,
and XACML are some of the key standards
SOA security currently focuses mainly on access control.
SOA-specific techniques to address intrusion detection,
denial of service and insider threat analysis need attention
33
Appendix
Bhavani Thuraisingham
The University of Texas at Dallas
Securing the network traffic:
SSL/TLS and IPsec

Secure Socket Layer SSL and Transport Layer Security are
used to provide transport level security for web services
applications.

Security features:





authentication
data integrity
data confidentiality
SSL/TLS enables point-to-point secure sessions.
IP security (IPsec) security features



secure sessions with host authentication
data integrity
data confidentiality
35
WS-Policy: Policy model

Policy:


Policy Alternative:




A potentially empty collection of policy alternatives. Alternatives are
not ordered
A potentially empty collection of policy assertions.
An alternative with zero assertions indicates no behaviors..
Alternatives are mutually exclusive (exclusive OR)
Policy Assertion:


Identifies a a requirement (or capability) of a policy subject.
Assertions indicate domain-specific (e.g., security, transactions)
semantics and are expected to be defined in separate, domainspecific specifications
36
WS-Policy example
<wsp:Policy>
<wsp:ExactlyOne>
<wsse:SecurityToken>
<wsse:TokenType>wsse:Kerberosv5TGT
</wsse:TokenType>
</wsse:SecurityToken>
<wsse:SecurityToken>
<wsse:TokenType>wsse:X509v3
</wsse:TokenType>
</wsse:SecurityToken>
</wsp:ExactlyOne>
</wsp:Policy>
Which security token we want to use among the various
tokens such as Kerberos and X509
37
WS-Policy

WS-Policy:


WS-PolicyAssertions:


Defines how to associate a policy with a service, either by directly
embedding it in the WSDL definition or by indirectly associating it
through UDDI
WS-SecurityPolicy:


Defines a few generic policy assertions
WS-Policy Attachment:


is an extensible model for expressing all types of domain-specific policy
models: transport-level security, resource usage policy, even end-to-end
business-process level policy. It Define basic policy, policy statement,
and policy assertion models. WSPolicy is also able to incorporate other
policy models such as SAML and XACML
Defines security policy assertions corresponding to the security claims
defined by WS-Security: message integrity assertion, message
confidentiality assertion, and message security token assertion
The only policy assertions standardized so far are those defined in
WS-SecurityPolicy (specific assertions that describe how messages
are secured) and WS-PolicyAssertions.
38
WS-Security mechanisms and
considerations

Mechanism(s)


Mechanisms for message integrity: digital signatures and certificates
Mechanism for confidentiality: encryption (XML Encryption)

Digital signatures alone do not provide message authentication. To
prevent replay attack (one can record a signed message and resend it),
digital signatures must be combined with timestamps or sequence
numbers to ensure the uniqueness of the message.

When digital signatures are used for verifying the identity of the sending
party, the sender must prove the possession of the private key. One way
to achieve this is to use a challenge-response type of protocol.

The combination of signing and encryption over a common data item
may introduce some cryptographic vulnerability:

For example, encrypting digitally signed data, while leaving the digital
signature in the clear, may allow plain text guessing attacks
39
WS-Security request example
1 <soap:Envelope>
2 <soap:Header>
3 <ws:Security>
4
<ws:BinarySecurityToken id="X509token" ValueType="X.509">
5
sdfOIDFKLSoidefsdflk …
6
</ws:BinarySecurityToken>
7
<ds:Signature>
8
<ds:Reference>
9
<ds:Ref URI="#PO"/>
10
</ds:Reference>
11
<ds:SignatureValue>akjsdflaksf</ds:SignatureValue>
12
<ds:KeyInfo>
13
<ws:BinarySecurityTokenReference URI="#X509token"/>
14
</ds:KeyInfo>
15
</ds:Signature>
16 </ws:Security>
17 </soap:Header>
18 <soap:Body>
19
<po:PurchaseOrder ID="PO"/>
20 </soap:Body>
40
21 </soap:Envelope>
WS-SecureConversation

Conversations focus on the public processes in which the participants of a Web
service engage; WSCL is Web Services Conversation Language.

Web Services Secure Conversation Language (WS-SecureConversation) February
2005

Status: revised public draft release provided for review and evaluation only

Main goal: provide secure communication across one or more messages.

Extends WS-Security mechanisms

Allows to authenticate a series of SOAP messages (conversation)
 by establishing and sharing between two endpoints a security context for a
message conversation using a series of derived keys to increase security.

The security context is defined as a new token type that is obtained using a binding
of WS-Trust

This allows for exchange in a potentially more efficient way keys or new key
material

Security Context


A security context is an abstract concept that refers to an established authentication state
and negotiated key(s) that may have additional security-related properties.
A security context token (SCT) is a representation of that security context abstract concept,
which allows a context to be named by a URI and used with WS-Security.
41
Security policies for Web
Services

The concept of Policy: Guiding principles and procedures

Security policy might mean different things to different people:


Firewall filtering rules

Access control policy

Privacy policy
Standards for Web Services Policies
 WS-Policy

XACML

XACML profile for Web Services

Approaches: “specialized” models & languages vs. one-sizefits-all framework
42
XACML Profile for Web-Services

OASIS XACML Profile for Web-Services XACML Working draft
04, 29 Sep 2003

Status: working draft

Main goal: extending XACML to deal with the specific
characteristics of Web services

Two main extensions to XACML:


define in a precise way the various aspects to which a security policy
applies to, for example for distinguishing the security policy that must be
applied to the message level from the access control policy applied to a
Web service or to an operation of the Web service

use of the policy combination mechanisms defined in XACML in order to
combine the preference/requirements policy of the Web service client
with the access control policy of the Web service provider
Note: XACML profile is not getting as much attention as it used to
43
SAML profiles





Defines constraints and/or extensions of the core protocols
and assertions in support of the usage of SAML for a
particular application.
Achieve interoperability.
Stipulates how particular statements are communicated
using appropriate protocol messages over specified
bindings.
E.g. Web Browser SSO Profile specifies how SAML
authentication assertions are communicated using the
Authentication Query and Response messages over a
number of different bindings in order to enable Single SignOn for a browser user
By agreeing to support a particular SAML profile (as
opposed to the complete specification set), parties who wish
to exchange SAML messages have a much simpler job of
achieving interoperability.
44
Policies and Policy Sets

Policy



Policy Set




Smallest element PDP can evaluate
Contains: Description, Defaults, Target, Rules, Obligations, Rule
Combining Algorithm
Allows Policies and Policy Sets to be combined
Use not required
Contains: Description, Defaults, Target, Policies, Policy Sets, Policy
References, Policy Set References, Obligations, Policy Combining
Algorithm
Combining Algorithms: Deny-overrides, Permit-overrides,
First-applicable, Only-one-applicable
46
Overview of the Policy
Element
<Policy>
<Target>
<Resources>
<Subjects>
<Actions>
<RuleSet ruleCombiningAlgId = “DenyOverrides”>
<Rule ruleId=“R1”>
<Rule ruleId=“R2”>
…
<Obligations>
<RuleSet>
</Policy>
<Rule RuleId=“R2”
Effect=“Deny”>
<Target>
<Rule RuleId=“R1”
<Resources>
Effect=“Permit”>
<Subjects>
<Target>
<Actions>
<Resources>
<Condition>
<Subjects>
</Rule>
<Actions>
<Condition>
</Rule>
47
Standards for security management:
XKMS
(XML Key Management Standard)
XML Key Management Specification (XKMS 2.0) Version
2.0 5 April 2004
Status: W3C Candidate Recommendation


XKMS provides a Web-based interface to existing public key infrastructure
(PKI)
XKMS specifies protocols for:




Distributing
Registering public keys
The protocol is suitable for use in conjunction with the standard for XML
Signatures [XML-SIG] and companion standard for XML Encryption [XMLENC].
The XML Key Management Specification (XKMS) defines two services:


the XML Key Information Service Specification (X-KISS) and
the XML Key Registration Service Specification (X-KRSS).
48
XKMS services
BOB
ALICE
XKMS protocol
XML Key Information
Service (X-KISS)
- locate a public key
- validate a public key
XML Key Registration
Service (X-KRSS)
- register
- reissue
- revoke
- recover
49
Standards for security
management: WS-TRUST


Security (confidentiality & integrity) is
achieved through encryption, digital
signatures and certificates
Ultimately, security depends on the secure
management of cryptographic keys and
security tokens:




Key/security token issuance
Key/security token transmission
Key/security token storage
Key/security token exchange
50
WS-Trust





Web Services Trust Language (WS-Trust) February 2005
Status: Initial public draft release provided for review and evaluation only
Main goal: to enable the issuance and dissemination of credentials
among different trust domains
WS-Trust defines extensions to WS-Security that provide:
 Methods for issuing, renewing, and validating security tokens.
 Ways to establish, assess the presence of, and broker trust
relationships.
Motivation: The recipient of a WS-Security-protected SOAP message
has three potential issues with the security token contained within the
Security header:
 Format: the format or syntax of the token is not known to the
recipient
 Trust -- the recipient may be unable to build a chain-of-trust from its
own trust anchors (e.g. its X.509 Certificate Authority, a local
Kerberos KDC, or a SAML Authority) to the issuer or signer of the
token
 Namespace -- the recipient may be unable to directly comprehend
the set of claims within the token because of syntactical differences
51
WS-Trust: trust model
52
WS-Trust: example
Client
The Client
uses X.509
certificate
Firewall

SOAP
Gateway
WS-Security
SOAP msg
STS
Service
NO previouos
trust
relationship
Provider
Web service
The Provider
understands
Kerberos
certificate
53
WS-* Security standards and
security



WS-* security standard specifications
address interoperability aspects
Each standard specification provides a
specific section describing security threats
that are not addressed by that specification
When using implementations of the
specifications, the above warnings must be
carefully analyzed
54
WS-* Security standards and
interoperability

Theory:



The framework mandates for a layered approach
every upper layer standard could/should re-use and
extend the specification of lower-layer standards.
Practice:



Specifications issued by different bodies are not always
compatible, but
Adherence to profiles improves interoperability
Implementations of different vendors are not always
interoperable
55
WS-* Security standards and
performance


XML induces overhead
Efficient ways of packaging and transmitting binary
data in SOAP messages are needed:





XML-binary Optimized Packaging (XOP)
SOAP Message Transmission Optimization Mechanism
(MTOM)
Resource Representation SOAP Header Block (RRSHB)
Processing of WS-* security compliant messages
require encryption/decryption and eventually
signature management capabilities
XML accelerators and the XML firewalls try to solve
those problems
56
XML Accelerators and Firewalls

Accelerators: A customized hardware and software performing the
following processing tasks:




XML/SOAP parsing,
XML schema validation,
XPath processing and XSLT transformation functions
Firewalls: Also known as XML gateways:



Perform functions of a XML accelerator
Support WS-Security standard
Additional functionalities:




content or metadata-based XML/SOAP filtering functions
XML messages encryption/decryption at the message or element level
XML signatures’ verification and XML message signing according to XML
Encryption standard
Authentication and authorization functions (that in some XML appliance can
be based on local or on off-board repositories)
57