 Web Services Basics revisited

 Web service security

 WS-Security Standard
 Security contexts
 SAML
 XACML
 CardSpace
 OpenID
 Summary
1. Why Web Services?
2. The Web Services Computing Stack.
3. Summary.
Livermore July 25 2001
 Web designed for application to human interactions
 Served very well its purpose:
 Information sharing: a distributed content library.
 Enabled B2C e-commerce.
 Non-automated B2B interactions.
 How did it happen?
 Built on very few standards: http + html
 Shallow interaction model: very few assumptions made
about computing platforms.
 Result was ubiquity.
 The Web is everywhere. There is a lot more we can do!
 E-marketplaces.
 Open, automated B2B e-commerce.
 Business process integration on the Web.
 Resource sharing, distributed computing.
 Current approach is ad-hoc on top of existing standards.
 e.g., application-to-application interactions with HTML forms.
 Goal:
enabling systematic application-to-application
interaction on the Web.
“Web services” is an effort to build a
distributed computing platform for the
Web.

Yet another one!

 Goals
 Enable universal interoperability.
 Widespread adoption, ubiquity: fast!
 Compare with the good but still limited adoption of the
OMG’s OMA.
 Enable (Internet scale) dynamic binding.
 Support a service oriented architecture (SOA).
 Efficiently support both open (Web) and more
constrained environments.
 Requirements
 Based on standards. Pervasive support is critical.
 Minimal amount of required infrastructure is
assumed.
 Only a minimal set of standards must be implemented.
 Very low level of application integration is
expected.
 But may be increased in a flexible way.
 Focuses on messages and documents, not on
APIs.
Web service applications are
encapsulated, loosely coupled
Web “components” that can
bind dynamically to each other
 Framework can be described in terms of

 What goes “on the wire”:

Formats and protocols.

 What describes what goes on the wire:

Description languages.

 What allows us to find these descriptions:

Discovery of services.
 SOAP 1.1 defined:
 An XML envelope for XML messaging,
 Headers + body
 An HTTP binding for SOAP messaging.
 SOAP is “transport independent”.
 A convention for doing RPC.
 An XML serialization format for structured data

 SOAP Attachments adds

 How to carry and reference data attachments
using in a MIME envelope and a SOAP envelope.
<SOAP-ENV:Envelope
xmlns="http://schemas.xmlsoap.org/soap/envelope/">

< SOAP-ENV:Header>
...
</ SOAP-ENV:Header>

< SOAP-ENV:Body>
...
</ SOAP-ENV:Body>
...
</ SOAP-ENV: Envelope>
 Internet-scale integration needs
a lingua-franca Context
Context
 XML messaging protocol
over HTTP: SOAP
Transactions
Transactions
 Intra-enterprise integration
needs to allow alternates: Routing
Routing
 CORBA, RMI

 Messaging Reliability
Reliability
 In-memory method calls
Security
Security

Attachments
Attachments

W3C
SOAP
SOAP
 Integration requires Agreements
Agreements
interoperable machine-
understandable descriptions Flows
Flowsand

WSFL
and
Composition
Composition
Enables dynamic, delayed Public
PublicFlows

binding of components. Flows

Service
ServiceQoS
QoS
 Language extensibility
provides support for different
Service
Service

WSDL
levels of application
integration.
Interface
Interface

XML
XMLSchema
Schema
 Provides functional description of network services:
 IDL description
 Protocol and deployment details
 Platform independent description.
 Extensible language.
 A short history:
 WSDL v1.0, 9/2000
 WSDL v1.1 submitted to W3C 3/2001.
 A de facto industry standard.
 Service

 portType
 Abstract definition of a Port Port
(e.g. http://host/svc)
service (set of
Binding Binding
operations) (e.g. SOAP)

 Multiple bindings per

portType: portType
 How to access it
 SOAP, JMS, direct call operation(s)
 Ports inMesage outMessage
 Where to access it
Abstract interface
1. As extended IDL: WSDL allows tools to generate
compatible client and server stubs.
 Tool support for top-down, bottom-up and “meet in the
middle” development.
1. Allows industries to define standardized service
interfaces.
2. Allows advertisement of service descriptions,
enables dynamic discovery and binding of
compatible services.
 Used in conjunction with UDDI registry
1. Provides a normalized description of
heterogeneous applications.
 Single stub can invoke services over different bindings
 Depends only on abstract interface.

 Are independent of binding (but pluggable).

 Add new bindings without recompiling/redeploying
stub

 Allows optimisations RMI-

IIOP
based on the bindings of service.
 Will support extended Client Proxy SOAP/
object HTTP
services models if described
In WSDL JMS/
MQ
 WSFL describes Web
Service compositions.
[ WS]
1. Usage patterns of Web
Services: describes [ WS]
workflow or business
processes.
2. Interaction patterns:
describes overall partner A
interactions.
C

B
 Activities
Control links define represent
execution flow as a units of
directed acyclic graph processing.
Activities are
[ WS]
associated with
specific typed
service providers

Flow of data is
modeled
through data
Activities can be
links.
mapped to the
flow interface
 “Public flows” provide a representation of the service behavior
as required by its users.
 Typically, an abstraction of the actual flow begin executed
 Defines a “behavioral contract” for the service.
 Internal implementation need not be flow-based.
 Flows are reusable: specify components types, but not what
specific services should be used!

 “Private flows” are the flows executed in practice.

 WSFL serves as a “portable flow implementation language”

 Same language is used in WSFL to represent both types of

processes.
 Global models describe how
the composed Web Services
interact.
A
 RosettaNet automated.
 Like an ADL.
C
 Interactions are modeled as
links between endpoints of
two service interfaces (WSDL
operations).
 An essentially distributed B
description of the interaction.
 Static binding
requires service
“libraries”.

 Dynamic binding
requires runtime Directory UDDI
Directory
discovery of meta-
data Inspection ADS,
Inspection DISCO
 UDDI defines the operation of a service
registry:
 Data structures for registering
 Businesses
 Technical specifications: tModel is a keyed reference to a
technical specification.
 Service and service endpoints: referencing the supported
tModels
 SOAP Access API
 Rules for the operation of a global registry
 “private” UDDI nodes are likely to appear, though.
 Web Service
Web Service

businessEntity
businessEntity
businessEntity
businessService Rosetta-Net
businessService
BASDA
bindingTemplate Simple.Buy
bindingTemplate
InstanceDetails Schemas,
InstanceDetails
Interchange specification

categoryBag tModels
SIC CODE
keyedReference
keyedReference NAICS

identifierBag
DUNS Numbers
keyedReference
keyedReference Thomas Registry ID
 The Web services framework is being defined,
standardized and supported by the industry at a
record pace.

 Broad industry acceptance and standard compliance

will make it ubiquitous.

 Will bring an unprecedented level of interoperability

to Web applications.

 The benefits of Web services, however, are not

limited to the Web!
 SOAP
http://www.w3c.org/TR/soap
 WSDL
http://www.w3c.org/TR/wsdl
 UDDI
http://www.uddi.org
 WSFL
http://www.ibm.com/software/webservices
 Protect messaging across domains
 Convey security information in messages
 Make security decisions and communicate them between
parties
 Tools at hand
 WS-Security, XML-Signature
 SAML
 XACML
 Digital certificate validation
 Content-filtering XML
 Filters based on data format (XSD)
 Filters based on content (XPath)
 Filters based on integrity (XML Signature)
 Web Services Security: SOAP Message Security
 1.0 (Oasis Standard 2004)
 1.1 (Oasis Standard 2006)
 Extensions in: security token support, message attachments and rights
management.
 End-to-End security
 Headers are decrypted and processed as needed
 Selective processing
 Some parts are plain text
 Some are encrypted
 Some are signed
 How does it work?
 SOAP header carries security information (and other info as well)
 Ability to send security tokens as part of a message,
message integrity, and message confidentiality
 Security model in terms of security tokens combined with
digital signatures to protect and authenticate SOAP
messages
 An X.509 is an example of a signed security token
endorsed by a CA.
 When third party support is not available, receiver may
choose to accept the claims in the token based on trust
on the entity that sent the message.
 Multiple security token formats
 Multiple trust domains

 Multiple signature formats

 Multiple encryption technologies

 Targeted message content security and

not just transport-level security
 Establishing a security context or
authentication mechanism
 Key derivation

 Advertisement and exchange of

security policy
 How trust is established or determined

 Non-repudiation
 Integrity mechanism designed to support multiple signatures
 Uses XML Signature and XML Encryption
 Syntax and semantics of signatures within a <wsse:Security>
element
 This is the security block in the SOAP header
 SOAP actor/role attribute is used to target header blocks
 Security element includes
 Security tokens
 Information about the use of XML Encryption & Signature in the
SOAP header/body/combination
 May be present multiple times in a SOAP message
 Must have different actor/role attribute values
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap=""..." xmlns:wsu="...” xmlns:wsse="...">
<soap:Header>
<wsse:Security soap:mustUnderstand=”..”>..</wsse...>
</soap:Header>
<soap:Body>
...
</soap:Body>
</soap:Envelope>

 Unrecognized extension elements or attributes

should cause a fault
 Receivers MAY ignore elements or extensions
within the <wsse:Security> element, based on
local security policy.
 But they must understand them first
 SOAP Faults are used to indicate faults
 Error scenarios
 Security token type unsupported
 Note: WS-Policy may be used to convey what security tokens can be understood
by different parties
 Fault code: InvalidSecurity (if contents of the header block cannot be processed)
 Invalid security token
 For example: security token corrupted or has invalid signature
 Fault code: InvalidSecurityToken
 Security token cannot be authenticated
 For example: given certificate cannot be validated
 Fault code: FailedAuthentication
 Security token unavailable
 For example: a certificate was referenced that could not be located
 Fault code: wsse:SecurityTokenUnavailable
 Builds on 1.0
 WS-Security 1.1 extensions include
 EncryptedKeyToken security token
 Represents a security token for an encrypted symmetric
key.
 EncryptedHeader block
 Protect any header block, also nested
 Digital signature confirmation
A digital signature confirmation is a SOAP message
that a Web service sends to a client that confirms
that it verified the client's digital signature.
 Remember Web Services goals:
 Re-use existing services
 Combine services from several domains

 Security result: Must support several

security domains
 SOAP intermediaries
 Reusing security tokens from one message
in another message
 Security Context II

Security Context I

HTTP POST SOAP

Web Appl. Web
Website
Browser Server Service

Main Point: We need security within AND

between security contexts!
 Security Context II

Security Context I

SOAP HTTP SOAP SMTP

Main Point: We need XML validation,

encryption, and authentication between
security contexts!
 XML
ID Management
LDAP
Management Authorization PKI
Console Single Sign-On
Authentication
Design and Content Checking
Deploy
Security Integrity Validation Reporting
policies Routing Activity
Alerting
XML Secure logging
Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp
 SAML (Security Assertion Markup Language)
 A XML-based framework (schemas) for the
exchange of authentication and authorization
information
 A standard message exchange protocol
 How you ask and receive information
 Mainly for integration, up to relying parties to
decide to what authentication authority to trust
 Assertions can convey information about
authentication acts performed by subjects,
attributes of subjects, and authorization
decisions about whether subjects are allowed to
access certain resources
 Authentication statements merely describe
acts of authentication that happened
previously
 Specified by OASIS
 XML-based framework for exchanging
security information
 XML-encoded security assertions
 XML-encoded request/response protocol

 Rules on using assertions with standard

transport and messaging frameworks
 SAML & WS-Security allow a SOAP message to
include information about the end-user’s
authentication status
 Domain A Domain B

User User

Service Service

Authentication Authentication
server A server B
Using services in B from A?
Authentication at B?
Not acceptable!
 Domain A Domain B

User User

Service Service

Authentication Authentication
server A server B

Timed Timed
updates updates
Authentication
server C
 An assertion is a declaration of fact about
a subject, e.g. a user
 According to some assertion issues
 SAML has three kinds, all related to
security:
 Authentication
 Attribute
 Authorization decision
 You can extend SAML to make you own
kinds of assertions
 Assertions can be digitally signed
 Issuer and issuance timestamp
 Assertion ID
 Subject
 Name plus the security domain
 Optional subject information, e.g. public key
 ”Conditions” under which assertion is valid
 SAML clients must reject assertions containing unsupported
conditions
 Special kind of condition: assertion validity period
 Additional ”advice”
 E.g. to explain how the assertion was made
 An issuing authority asserts that:
 Subject S
 was authenticated by means M
 at time T
 Caution: actually checking or revoking of
credentials is not in the scope of SAML!
 Password exchange
 Challenge-response
 Etc.
 It merely lets you link back to acts of
authentication that took place previously
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="127.0.0.1.1234567"
Issuer="Example Corp"
IssueInstant="2005-04-04T09:00:00Z">
<saml:Conditions
NotBefore="2005-04-04T09:00:00Z"
NotAfter=""2005-04-04T09:05:00Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="password"
AuthenticationInstant="2005-04-04T09:01:00Z">
<saml:Subject>
<saml:NameIdentifier
SecurityDomain="example.com"
Name="johndoe"/>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
Assertion type Description
Authentication Assertion Asserts that subject S was
authenticated by means M at time T

Attribute Assertion Asserts that subject S is associated

with attributes A1, A2,… with values
V1,V2,...

Authorization Decision Should the request to subject S for

Assertion access type A be granted to
resource R given evidence E
 Integrated with Liberty specifications
and the result is SAML 2.0, which
OASIS ratified in March 2006. Backed
SAML 2.0 by multiple vendors (IBM, BEA, ..)

Shibboleth

Liberty ID-FF WS-Federation

Backed by Microsoft

SAML 1.1 WS-Trust

WS-Security

HTTP SOAP
 XACML 2.0 and all the associated profiles were approved as OASIS
Standards on 1 February 2005.
 XACML defines three top-level policy elements: <Rule>, <Policy> and
<PolicySet>. The
 <Rule> element contains a Boolean expression that can be evaluated in
isolation, but that is not intended to be accessed in isolation by a PDP. So,
it is not intended to form the basis of an authorization decision by itself.
It is intended to exist in isolation only within an XACML PAP, where it may
form the basic unit of management, and be re-used in multiple policies.
 The <Policy> element contains a set of <Rule> elements and a specified
procedure for combining the results of their evaluation. It is the basic unit of
policy used by the PDP, and so it is intended to form the basis of an
authorization decision.
 Defines algorithms arriving at an authorization decision given the
input rules and policies
 An operation that should
be performed by the
PEP in conjunction with
the enforcement of
authorization decision

Boolean Permit or
expression deny

Source: http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
 SOAP msg is
Once the SAML authoriz. Has ben made
Intercepted. SAML query is formed, results
it may be included into the SOAP
determine access. Identity info taken from
message and used by the target WS.
request. There may be multiple PEPs.

WS request (SOAP) WS request

PEP
Policy Enforcement Point Web Service
PDP queries attributes
Once the PDP has all the from PIP (time of day,
SAML Authrz. decision relevant information, it evaluates
Reply
query
value, etc.). PIP returns
rules andInfo
returns a SAML
request an attribute assertion.
authoriz. Assertion
PDP PIP
Policy Decision Point Policy Information Point
Attribute assertion

XACML Policy request Rules are combined:

Policy (XACML)
subjects, resources,
and attributes.
Exported into XACML.
PRP Policy Store
Policy Retrieval Point
(XACML)

PAP
Policy Admin. Point
 Trust Services Integration Kit (TSIK), Verisign
 Java API for creating trusted services, includes a SAML API
 http://www.xmltrustcenter.org/developer/verisign/tsik/index.htm
 Apache XML-Security, Apache Software Foundation
 XML Digital Signature and XML Encryption (Java, C++)
 http://xml.apache.org/security/
 Web Services Enhancements 2.0, Microsoft
 .NET implementation of various WS Security specs.
 http://msdn.microsoft.com/webservices/building/wse/
 Microsoft Passport, Microsoft
 Single sign-on support
 XML Security Suite, IBM
 XML Digital Signature, XML Encryption and XML Access Control Language
(Java)
 http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
 SunONE Identity Server, Sun Microsystems
 Supports Liberty’s federated identity and SAML
 Implements many of the rules of the WS-* specifications
 Works with HTTP and SOAP (SoapExtensions)
 Supported specifications
 WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust,
WS-Referral, WS-Addressing, WS-Policy, WS-Attachments
 3.0 supports WS-Security 1.1
 Supports signing/encrypting message elements and policies
 Overview
 http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnwse/html/newwse3.asp
 Common scenarios/patterns for securing messaging
 UsernameOverTransport (username+pass&SSL)
 UsernameForCertificate (username+pass&X.509 server auth)
 AnonymousForCertificate(X.509 server auth)
 MutualCertificate10 (X.509 client&server auth WS-S 1.0)
 MutualCertificate11 (X.509 client&server auth WS-S 1.1)
 Kerberos (Windows)
 Implemented using policy files
 Tokens and web farms
 http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnwebsrv/html/sctinfarm.asp
<mutualCertificate11Security
clientActor
establishSecurityContext="true|false"
messageProtectionOrder="Signature and encryption order"
renewExpiredSecurityContext="true|false"
requireDerivedKeys="true|false"
requireSignatureConfirmation="true|false"
serviceActor
ttlInSeconds >
<clientToken/>
<serviceToken/>
<protection/>
</mutualCertificate11Security >

Note that both the client and server need to share part of the profile.
 Intended to solve two problems
 to be an identity provider to MSN
 identity provider for the Internet
 First goal
 over 250 million active Passport accounts and
 1 billion authentications per day
 Second goal
 What is the role of the identity provider in transactions?
 Passport no longer stores personal information other than
username/password credentials
 Authentication service for sites
 Proprietary technology
 Roadmap: towards identity card (CardSpace)
 Interface for identity based authentication and authorization
 Identity cards that people can choose (Identity Metasystem)
 Integration with Web sites
 Consistent user interface
 Windows Live ID
 Unified login service for Microsoft sites such as Hotmail, MSNBC,
MSN, ..
 Used also for ad targeting with adCenter
 Has been opened for Web site developers (August, 2007)
 CardSpace (Microsoft)
 Multiple identities
 Interface for identity based authentication and
authorization
 Identity cards that people can choose
 Integration with Web sites
 Consistent user interface
 Microsoft plans to implement this
 ActiveX, WS-*
 http://www.identityblog.com/
Source: http://www.identityblog.com/
 OpenID is a decentralized sign-on system for the Web
 Not a real single sign-on solution, does not support authorization
 Instead of usernames and passwords, users need to have an
account with some identity provider
 The user has the choice of selecting a suitable identity
provider
 Support: AOL, Orange, FireFox, Microsoft planning support in
Vista, LiveJournal, Wikitravel, Zooomr, Ma.gnolia
 Estimated 120 million OpenIDs on the Internet
 OpenID 2.0 supports discovery
 Yadis provides a mechanism for determining the services that
are available with a given identifier
 Identity aggregation: ClaimID
 Claim Web resources under your OpenID (must have write
permission)
 There are two ways to obtain an OpenID-enabled
URL that can be used to login on all OpenID-
enabled websites.
 To use an existing URL that one's own control (such as
one's blog or home page), and if one knows how to edit
HTML, one can insert the appropriate OpenID tags in the
HTML code following instructions at the OpenID
specification.
 The second option is to register an OpenID identifier with
an identity provider. They offer the ability to register a
URL (typically a third-level domain) that will automatically
be configured with OpenID authentication service.
End User Relying Party(Site) OpenID Provider

Visits

OpenID login page

Login using OpenID

Normalization, discovery

Association (optional)

Handle

Request authentication
HTTP/Form Redirect

Potential user
interaction
Auth. response

User is authenticated
Verify response
 Security contexts
 Security needed within and between contexts
 XML validation, encryption, and authentication needed
between security contexts!
 WS security standard revisited
 SOAP header carries security information (and other info as well)
 Selective processing
 SAML
 Statements about authorization, authentication, attributes
 SAML & WS-Security & XACML
 OpenID and Live ID
 Implementations available