XML Web Services Security
March 27, 2003
IIDS Group, Vrije Universiteit
Yuri Demchenko, NLnet Labs
<demch@NLnetLabs.nl>
Outlines




Historical
XML Security
Web Services Security
OGSA Security
 XML Web Services technology for IIDS - Discussion
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_2
Historical: How all this started (quoting Tim Berners-Lee)
 Initial idea to create resource description language
Existing technologies: SGML + WAIS, Gopher + Library Catalogues
 Problems: hyperlinks reference and semantic meaning binding

 Past steps:
WWW and HTML
 RDF and Metadata
 XML and XML Signature

 Next step: Semantic Web
 Ongoing development:
Computer Grids -> Information Grids -> Semantic Grids
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_3
XML Basics: DTD, Schema, XML Protocol, etc.
DTD is document-oriented
 Like HTML
Schema is data-oriented
 XML Signature
 SAML
Basic XML Protocol(s)
 XML-RPC
 SOAP
XForms, XLink, XML Query, XPath, XPointer, XSL and XSLT, Legal XML
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_4
XML Security vs Traditional (Network) security
Traditional Security:




Host-to-host or point-to-point security
Client/server oriented
Connection or connectionless oriented
Generically single/common trust domain/association
XML Security
 Document oriented approach

Security tokens/assertions and policies can be associated with the document or its
parts
 Intended to be cross-domain
 Potentially for virtual and dynamic trust domains (security associations)
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_5
XML Security - Components
 XML Signature
 XML Encryption
 Security Assertion
SAML (Security Assertion Mark-up Language)
 XrML (XML Right Mark-up Language)
 XACML (XML Access Control Mark-up Language)

 XKMS (XML Key Management Specification)
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_6
XML Signature: Features
Fundamental feature: the ability to sign only specific portions of the XML tree
rather than the whole document.
 XML document may have a long history when different component are authored
by different parties at different times
 Different parties may want to sign only those elements relevant to them
 Important when keeping integrity of certain parts of an XML document is
essential while leaving the possibility for other parts to be changed
 Allows carrying security tokens/assertions on document/data rather than on
user/client
 Provides security features for XML based protocols

Provides basic functionality for state assertions
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_7
XML Signature structure
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_8
File/Document Encryption vs XML Encryption
FileA/
DocA
Encrypt
with/for
pubK B
Encrypted
File
(pubK B)
Decrypt
with
privK B
FileA/
Doc
User B
Only User B can open
FileA with pirvK B
Decrypt
with
privK B
Doc1
User B can read whole
Doc1 and decrypt only
part B
Decrypt
with
privK C
Doc1
User A
(knows
pubK B)
XML
Doc1
Encrypt
select parts
for
select targets
Encrypted
select
B
parts
C
D
User A
(knows pubK B,C, D)
C
D
B
D
User C can read whole
Doc1 and decrypt only
part D
 For multi-user encryption Document can contain encrypted shared decryption key
with pubK of all intended targets
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_9
Binding semantics to the document with XMLSig
Signed selected
parts
XML
Doc1/
JobDescr
Signed selected
parts
SigB
SigB
SigC
XMLSigA
Signed selected
parts
Signed selected
parts
SigB
SigC
SigB
SigC
SigD
XMLSigA
XMLSigA
XMLSigA
SigD
XMLSigA
XMLSigA
SigB
User/System A
creates XML
Doc1 and signs
with SigA
Users/Systems B, C, D sign selected parts with their privK B, C, D
• Can add new information and re-sign document
SigC
SigD
Receiver validates integrity
of XML Doc1 by validating
all signatures
 XML Signature allows signing selected parts of the document
Providing Integrity and Authenticity
 Binding attributes and permissions to the the Document

March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_10
XML Web Services
A Web Service is a software system identified by URI, whose public interfaces and
bindings are defied and described by XML. Other software systems may discover
and interact with the Web Service in a manner prescribed by its definition, using
XML based messages conveyed by Internet protocols.
 Service oriented architecture for application-to-application interaction



Describing Web services – WSDL
Exchanging messages – SOAP extensions
Publishing and Discovering WS descriptions - UDDI
 Programming language-, programming model-, and system software-neutral
 Standard based: XML/SOAP foundation
 Industry initiatives (and development platforms)




Sun SunONE/J2EE (SunONE Studio)
Microsoft .NET (Visual Studio .NET)
IBM Dynamic e-Business (AlphaWorks)
XML Spy by Altova
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_11
XML WS - Service Oriented Architecture
• WSDL based Service
Description
• SOAP based messaging
over HTTP, SMTP, TCP,
etc.
• UDDI based
Publishing/Discovery
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_12
Web services features – three stacks
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_13
Web Service Description Language (WSDL)
•
•
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
WSDL is an XML document format
for describing Web service as a set of
endpoints operating on messages
containing either document-oriented
or procedure-oriented (RPC)
messages.
The operations and messages are
described abstractly and then bound to
a concrete network protocol and
message format to define an endpoint
Slide2_14
Web Services Security Model
WS-Security model provides end-to-end security (as contrary to point-to-point)
allowing intermediaries
 A Web service can require that an incoming message prove a set of claims (e.g.,
name, key, permission, capability, etc.).

Set of required claims and related information is referred as a Policy.
 A requester can send messages with proof of the required claims by associating
security tokens with the messages.

Messages both demand a specific action and prove that their sender has the claim to
demand the action.
 When a requester does not have the required claims, the requester or someone
on its behalf can try to obtain the necessary claims by contacting other Web
services.

Security token services broker trust between different trust domains by issuing
security tokens.
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_15
Web Services Security Model
Security token types
•Username/password
•X.509 PKC
•SAML
•XrML
•XCBF
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_16
WS Security Scenarios
All are built on SOAP based security tokens exchange








Direct Trust using username/password (using SSL/TLS)
Direct Trust using security token
Security token acquisition
Issued security token
Enforcing business policy
Web clients
Mobile clients (gateway services)
Enabling Federations
Using trust chaining, security token exchange, credentials exchange
 Supporting delegation

 Access control
 Auditing
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_17
Web Services Security Architecture
WSSecureConversation
WS-Federation
WS-Authorisation
WS-Policy
WS-Trust
WS-Privacy
WS Security
SOAP Foundation
WS-Security: describes how to attach signature and encryption headers to SOAP messages. In
addition, it describes how to attach security tokens, including binary security tokens such as
X.509 certificates, SAML, Kerberos tickets and others, to messages.
Core Specification - Web Services Security: SOAP Message Security
http://www.oasis-open.org/committees/download.php/1043/WSS-SOAPMessageSecurity-11-0303.pdf
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_18
Web Service Security – others specifications
WS-Policy: will describe the capabilities and constraints of the security (and other business)
policies on intermediaries and endpoints (e.g. required security tokens, supported encryption
algorithms, privacy rules)
WS-Trust: will describe a framework for trust models that enables Web services to securely
interoperate
WS-Privacy: will describe a model for how Web services and requesters state privacy
preferences and organizational privacy practice statements
WS-SecureConversation: will describe how to manage and authenticate message exchanges
between parties including security context exchange and establishing and deriving session
keys
WS-Federation: will describe how to manage and broker the trust relationships in a
heterogeneous federated environment including support for federated identities
WS-Authorization: will describe how to manage authorization data and authorization policies
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_19
WS Security: SOAP Message Security
SOAP Message Security must support a wide variety of security models.
Key driving requirements for the specification:




Multiple security tokens for authentication or authorization
Multiple trust domains
Multiple encryption technologies
End-to-end message-level security and not just transport-level security
Primary security concerns
 Protection against interception – confidentiality

XML Encryption
 Protection against illegal modification – integrity

XML Signature
 Security consideration – Auditing


Timestamping and message expiration
Sequence number and Messages correlation
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_20
SOAP Message Security Model
Describe abstract message security model in terms of security tokens combined
with digital signatures as proof of possession of the security token (key).
 Security token asserts claims and signatures provide mechanism for proving the
sender’s knowledge of key
 A claim can be either endorsed or unendorsed by a trusted authority

An X.509 Cert, claiming the binding between one’s identity and public key, is an
example of a endorsed/signed security token
 An unendorsed claim can be trusted if there is trust relations between the sender
and the receiver (usually based on historical relations/communications context)

Proof-of-Possession (e.g. username/password) – special type of unendorsed claim
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_21
WS-Security SOAP message structure
SOAP Header
URI: http://schemas.xmlsoap.org/ws/2002/04/secext
SOAP Routing
Namespaces used in WSSL:
SOAP
S http://www.w3.org/2001/12/soap-envelope
XML Digital Sign
ds http://www.w3.org/2000/09/xmldsig#
XML Encryption
xenc http://www.w3.org/2001/04/xmlenc#
XML/SOAP Routing m http://schemas.xmlsoap.org/rp
WSSL
wsse
http://schemas.xmlsoap.org/ws/2002/04/secext
Security token
Digital signature
DigSignature description:
Normalisation
Transformation
Signed elements
DigSignature value
Ref to DSign Sec token
SOAP Message payload
March 27, 2003. Vrije Universiteit, Amsterdam
Security element
 Header block targets specific receiver SOAP Actor
 Multiple header blocks are allowed targeted at different
Actors
 New header block are added/appended to existing ones
XML Web Services Security
Slide2_22
SecurityTokenReference Model
Usage and processing models for the <wsse:SecurityTokenReference> element.
 Local Reference – A security token, that is included in the message in the
<wsse:Security> header, is associated with an XML Signature.
 Remote Reference – A security token, that is not included in the message but
may be available at a specific URI, is associated with an XML Signature.
 Key Identifier – A security token, which is associated with an XML Signature
and identified using a known value that is the result of a well-known function of
the security token (defined by the token format or profile).
 Key Name – A security token is associated with an XML Signature and
identified using a known value that represents a "name" assertion within the
security token (defined by the token format or profile).
 Format- Specific References – A security token is associated with an XML
Signature and identified using a mechanism specific to the token
 Non-Signature References – A message may contain XML that does not
represent an XML signature, but may reference a security token (which may or
may not be included in the message).
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_23
Computer Grids
• Originated from Distributing Supercomputing
 To become “pluggable” computing resource
 Computer Grids -> Information Grids -> Semantic Grids
• Current de-facto standard – Globus Toolkits
• Open Grid Services Architecture was boosted by developing XML Web
Services – 2002
 Commercial Grids are starting
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_24
Open Grid Services Architecture (OGSA)
 WSDL extensions to describe specifics of Grid Services
Defines new portType - GridService
 Provides mechanism to create Virtual Organisation
 Provides mechanism to create transient services - Factories
 Provides soft-state registration of GSH - Registry

 Grid services can maintain internal state for the lifetime of the service. The
existence of state distinguishes one instance of a service from another that
provides the same interface.
 OGSA services can be created and destroyed dynamically
 Grid Service is assigned globally (persistent) unique name, the Grid service
handle (GSH)
 Grid services may be upgraded during their lifetime and referenced by Grid
(dynamic) service reference (GSR)
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_25
Security Issues in Grid computing - Specifics
General issues:
 Traditional systems are user/client/host centric
 Grid computing is data centric
Traditional systems:
 Protect system from its users
 Protect data of one user from compromise
In Grid systems:
 Protect applications and data from system where computation execute
 Stronger/mutual authentication needed (for users and code)

Ensure that resources and data not provided by a attacker
 Protect local execution from remote systems
 Different admin domains/Security policies
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_26
Security Issues in Grid computing - Components
 Authentication
Password based
 Kerberos based (authentication and key distribution protocol)
 SSL authentication
 PKI/Cert based

 Authorisation
 Integrity and confidentiality

Cryptography
 Assurance
 Accounting
 Audit
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_27
Authentication
Traditional systems:
 Authenticate user/client to protect system
Grid systems:
 Mutual authentication required

Ensure that resources and data not provided by a attacker
 Delegation of Identity
Process that grants one principal the authority to act as another individual
 Assume another’s identity to perform certain functions
 E.g., in Globus: use gridmap file on a particular resource to map authenticated user
user onto another’s account, with corresponding privileges

 Data origin authentication
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_28
Authorisation
Traditional systems:
 Determine whether a particular operation is allowed based on authenticated
identity of requester and local information
Grid systems:
 Determine whether access to resource/operation is allowed

Access control list associated with resources, principal or authorised programs
 Distributed Authorisation
Distributed maintenance of authorisation information
 One approach: Embed attributes in certificates

– Restricted proxy: authorisation certificate that grants authority to perform operation on
behalf of grantor

Alternative: separate authorisation server
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_29
Assurance, Accounting, Audit
 Assurance

When service is requested, to assure that candidate service provider meets
requirements
 Accounting

Means of tracking, limiting or changing for consumption of resources
 Audit
Record operations performed by systems and associate actions with
principals
 Find out what went wrong: typical role of Intrusion Detection Systems

March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_30
OGSA Security
Built upon WS Security
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_31
OGSA Security Roadmap - Specifications (1)
Naming




OGSA Identity Specification
OGSA Target/Action Naming Specification
OGSA Attribute and Group Naming Specification
Transient Service Identity Acquisition Specification
Translating between Security Realms




Identity Mapping Service Specification
Generic Name Mapping Specification
Policy Mapping Service Specification
Credential Mapping Service Specification
Authentication Mechanism Agnostic
 Certificate Validation Service Specification
 OGSA-Kerberos Services Specifications
Pluggable Session Security
 GSSAPI-SecureConversation Specification
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_32
OGSA Security Roadmap - Specifications (2)
Pluggable Authorization Service
 OGSA-Authorization Service Specification
Authorization Policy Management
 Coarse-grained Authorization Policy Management Specification
 Fine-grained Authorization Policy Management Specifications
Trust Policy Management
 OGSA Trust Service Specification
Privacy Policy Management
 Privacy Policy Framework Specification
VO Policy Management
 VO Policy Service Specification
Delegation
 Identity Assertion Profile Specification
 Capability Assertion Profile Specification
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_33
OGSA Security Roadmap - Specifications (3)
Firewall "Friendly"
 OGSA Firewall Interoperability Specification
Security Policy Expression and Exchange
 Grid Service Reference and Service Data Security Policy Decoration
Specification
Secure Service Operation
 Secure Service’s Policy and Processing Specification
 Service Data Access Control Specification
Audit and Secure Logging
 OGSA Audit Service Specification
 OGSA Audit Policy Management Specification
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_34
Trust establishment process (1)
1. Binding an entity identity to a Distinguished Name (“DN” - the subject name in an X.509
identity certificate)
 Trust in this step is accomplished through the (published and audited) policy based identity
verification procedures of the Certification Authority that issues the identity certificates
2. Binding a public key to the DN (generating an X.509 certificate)
 Trust in this step is accomplished through the (published and audited) policy based operational
procedures of the issuing Certification Authority (“CA”).
3. Assurance that the public key that is presented actually represents the user
 Trust in this step comes from the cryptography and protocols of Public Key Infrastructure.
4. Assurance that a message tied to the entity DN could only have originated with that entity:
 Trust that a message signed by a private key could only have been signed by the private key
corresponding to the public key (and therefore the named entity via X.509 certs) comes from public
key cryptography
 Trust in this step is also through user key management (the mechanism by which the user limits the
use of its identity), which is assured by user education, care in dealing with one’s cyber
environment, and shared understanding as to the significance of the private key.
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_35
Trust establishment process (2)
5. Mutual authentication, whereby two ends of a communication channel agree on each
other’s identity
 Trust in this step is through the cryptographic techniques and protocols of the Transport
Level Security (“TLS”) standard.
6. Delegation of identity to remote Grid systems
 Trust in this step is through the cryptographic techniques and protocols for generating,
managing, and using proxy certificates that are directly derived from the CA issued
identity certificates.
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_36
Remote Authentication, Delegation, and Secure
Communication in GRID
 Remote authentication is accomplished by techniques that verify a cryptographic identity
in a way that establishes trust in an unbroken chain from the relying party back to a
named human, system, or service identity. This is accomplished in a sequence of trusted
steps, each one of which is essential in order to get from accepting a remote user on a
Grid resource back to a named entity.
 Delegation involves generating and sending a proxy certificate and its private key to a
remote Grid system so that remote system may act on behalf of the user. This is the
essence of the single sing-on provided by the Grid: A user / entity proves its identity
once, and then delegates its authority to remote systems for subsequent processing steps.
 A secure communication channel is derived from the Public Key Infrastructure process
and the IETF Transport Level Security protocol.
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_37
Globus Grid Security Infrastructure (GSI)
Operational solution providing security infrastructure for Globus Toolkits
 Targeted problems:


Thousands of users – thousands of Certs – many of CAs (with different policies)
Grid-wide user group and roles are needed
– No grid-wide logging or auditing

Need for anonymous users
 Intended to evolve into OGSA Security
GSI Components
 Proxy Certificate Profile

Provides proxy credentials to allow for single sign-on and to provide delegated credentials for
use by agent and servers
 Online Credential Retrieval to create and manage proxy certificates
 Impersonation certificate and restricted delegation certificate
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_38
Proxy Certificate Profile
 Impersonation – used for Single-Sign-On and Delegation
Unrestricted Impersonation
 Restricted Impersonation defined by policy

 Proxy with Unique Name
Allows using in conjunction with Attribute Cert
 Used when proxy identity is referenced to 3rd party, or interact with VO policy

Proxy Certificate (PC) properties:
 It is signed by either an X.509 End Entity Certificate (EEC), or by another PC. This EEC or
PC is referred to as the Proxy Issuer (PI).
 It can sign only another PC. It cannot sign an EEC.
 It has its own public and private key pair, distinct from any other EEC or PC.
 It has an identity derived from the identity of the EEC that signed the PC.
 Although its identity is derived from the EEC's identity, it is also unique.
 It contains a new X.509 extension to identify it as a PC and to place policies on the use of
the PC. This new extension, along with other X.509 fields and extensions, are used to
enable proper path validation and use of the PC.
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_39
Reference: PKC vs AC: Purposes
 X.509 PKC binds an identity and a public key
 AC is a component of X.509 Role-based PMI
AC contains no public key
 AC may contain attributes that specify group membership, role, security clearance, or
other authorisation information associated with the AC holder
 Analogy: PKC is like passport, and AC is like entry visa

 PKC is used for Authentication and AC is used for Authorisation
– AC may be included into Authentication message
 PKC relies on Certification Authority and AC requires Attribute Authority (AA)
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_40
PKC vs AC: Certificates structure
X.509 PKC
 Version
 Serial number
 Signature
 Issuer
 Validity
 Subject
 Subject Public key info
 Issuer unique identifier
 Extensions
March 27, 2003. Vrije Universiteit, Amsterdam
AC









Version
Holder
Issuer
Signature
Serial number
Validity
Attributes
Issuer unique ID
Extensions
XML Web Services Security
Slide2_41
X.509 PKC Fields and Extensions – RFC 3280
X.509 PKC Fields
 Serial Number
 Subject
 Subject Public Key
 Issuer Unique ID
 Subject Unique ID
X.509 PKC Extensions
 Standard Extensions







X.509 PKC Fields
 Private Extensions




Authority Information Access
Subject Information Access


 Custom Extensions


March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Authority Key Identifier
Subject Key Identifier
Key Usage
Extended Key Usage
CRL Distribution List
Private Key Usage Period
Certificate Policies
Policy Mappings
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Slide2_42
AC Attribute Types and AC Extensions
AC Attribute Types
 Service Authentication Information
 Access Identity
 Charging Identity
 Group
 Role
 Clearance
 Profile of AC
March 27, 2003. Vrije Universiteit, Amsterdam
AC Extensions
 Audit Identity
To protect privacy and provide
anonymity
 May be traceable via AC issuer





AC Targeting
Authority Key Identifier
Authority Information Access
CRL Distribution Points
XML Web Services Security
Slide2_43
Other Technologies to look for IIDS
• SIP (Session Initiation Protocol) based technologies
• Instant Messaging and Presence Protocol – SIP based
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_44
XML Web Services technologies for IIDS
Discussion
March 27, 2003. Vrije Universiteit, Amsterdam
XML Web Services Security
Slide2_45