web services xml ws security architectures

8/8/2019 Web Services XML WS Security Architectures

1/69


2/69

Web Services Basics revisitedWeb service securityWS-Security Standard

Security contexts SAMLXACMLCardSpaceOpenID Summary


3/69


4/69

1. Why Web Services?

2. The Web Services Computing Stack.

3. Summary.


5/69

Livermore July 25 2001


6/69

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.


7/69

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-applicationinteraction on the Web.


8/69

Web services is an effort to build adistributed computing platform for the

Web.

Yet another one!


9/69

Goals Enable universal interoperability.Widespread adoption, ubiquity: fast!

Compare with the good but still limited adoption of theOMGs OMA.

Enable (Internet scale) dynamic binding. Support a service oriented architecture (SOA).

Efficiently support both open (Web) and more

constrained environments.


10/69

Requirements Based on standards. Pervasive support is critical.

Minimal amount of required infrastructure isassumed.Only a minimal set of standards must be implemented.

Very low level of application integration isexpected.But may be increased in a flexible way.

Focuses on messages and documents, not onAPIs.


11/69

Web service applications areencapsulated, loosely coupledWeb components that canbind dynamically to each other


12/69


13/69

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.


14/69

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 addsHow to carry and reference data attachments

using in a MIME envelope and a SOAP envelope.


15/69

< SOAP-ENV:Header>

...

< SOAP-ENV:Body>

...

...


16/69

Internet-scale integration needsa lingua-franca

XML messaging protocolover HTTP: SOAP

Intra-enterprise integrationneeds to allow alternates:

CORBA, RMI

Messaging

In-memory method calls

SOAPSOAP

SecuritySecurity

AttachmentsAttachments

ReliabilityReliability

RoutingRouting

TransactionsTransactions

ContextContext

W3C


17/69

Integration requiresinteroperable machine-

understandable descriptions

Enables dynamic, delayedbinding of components.

Language extensibility

provides support for differentlevels of applicationintegration.

InterfaceInterface

Service QoSService QoS

ServiceService

Public FlowsPublic Flows

Flows andCompositionFlows and

Composition

AgreementsAgreements

WSDL

WSFL

XML SchemaXML Schema


18/69

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.


19/69

portType Abstract definition of a

service (set ofoperations)

Multiple bindings perportType: How to access it

SOAP, JMS, direct call

Ports Where to access it

Service

Port(e.g. http://host/svc)

Binding(e.g. SOAP)

Abstract interface

portType

operation(s)

inMesage outMessage

Port

Binding


20/69

1. As extended IDL: WSDL allows tools to generatecompatible client and server stubs. Tool support for top-down, bottom-up and meet in the

middle development.

1.

Allows industries to define standardized serviceinterfaces.

2. Allows advertisement of service descriptions,enables dynamic discovery and binding ofcompatible services.

Used in conjunction with UDDI registry1. Provides a normalized description of

heterogeneous applications.


21/69

Client Proxy

object

RMI-

IIOP

JMS/

MQ

SOAP/

HTTP

Single stub can invoke services over different bindings Depends only on abstract interface.

Are independent of binding (but pluggable).

Add new bindings without recompiling/redeployingstub

Allows optimisations

based on the bindings of service.

Will support extended

services models if described

In WSDL


22/69

WSFL describes WebService compositions.

1.Usage patterns of Web

Services: describesworkflow or businessprocesses.

2. Interaction patterns:describes overall partnerinteractions.

A

B

C

[ WS]

[ WS]


23/69

Activitiesrepresent

units ofprocessing.

Flow of data ismodeledthrough datalinks.

[ WS]

Activities can bemapped to theflow interface

Control links defineexecution flow as a

directed acyclic graphActivities areassociated withspecific typedservice providers


24/69

Public flows provide a representation of the service behavioras 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 whatspecific 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 ofprocesses.


25/69

Global models describe how

the composed Web Services

interact.

RosettaNet automated. Like an ADL.

Interactions are modeled as

links between endpoints of

two service interfaces (WSDLoperations).

An essentially distributed

description of the interaction.

A

B

C


26/69

Static bindingrequires servicelibraries.

Dynamic bindingrequires runtimediscovery of meta-data InspectionInspection

DirectoryDirectory

ADS,DISCO

UDDI


27/69

UDDI defines the operation of a serviceregistry: Data structures for registering

BusinessesTechnical 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.


28/69

Web Service

Web Service

SIC CODENAICS

DUNS NumbersThomas Registry ID

Rosetta-NetBASDASimple.Buy

Schemas,

Interchange specification

businessEntitybusinessEntitybusinessEntity

businessServicebusinessService

bindingTemplatebindingTemplate

InstanceDetailsInstanceDetails

categoryBagkeyedReferencekeyedReference

identifierBag

keyedReferencekeyedReference

tModels


29/69


30/69

The Web services framework is being defined,standardized and supported by the industry at arecord pace.

Broad industry acceptance and standard compliancewill make it ubiquitous.

Will bring an unprecedented level of interoperabilityto Web applications.

The benefits of Web services, however, are notlimited to the Web!


31/69


32/69


33/69

Web Services Security: SOAP Message Security 1.0 (Oasis Standard 2004) 1.1 (Oasis Standard 2006)

Extensions in: security token support, message attachments and rightsmanagement.

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)


34/69

Ability to send security tokens as part of a message,message integrity, and message confidentiality

Security model in terms of security tokens combined withdigital 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 maychoose to accept the claims in the token based on trust

on the entity that sent the message.


35/69

Multiple security token formatsMultiple trust domains

Multiple signature formats

Multiple encryption technologies

Targeted message content security andnot just transport-level security


36/69

Establishing a security context orauthentication mechanism

Key derivation

Advertisement and exchange ofsecurity policy

How trust is established or determined

Non-repudiation


37/69

Integrity mechanism designed to support multiple signatures Uses XML Signature and XML Encryption

Syntax and semantics of signatures within a 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 theSOAP header/body/combination


38/69

May be present multiple times in a SOAP message Must have different actor/role attribute values

Unrecognized extension elements or attributesshould cause a fault

Receivers MAY ignore elements or extensionswithin the element, based onlocal security policy. But they must understand them first

..

...


39/69

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


40/69

Builds on 1.0WS-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 confirmationA digital signature confirmation is a SOAP message

that a Web service sends to a client that confirmsthat it verified the client's digital signature.


41/69

Remember Web Services goals: Re-use existing servicesCombine services from several domains

Security result: Must support severalsecurity domainsSOAP intermediaries

Reusing security tokens from one messagein another message


42/69

Web

BrowserWebsite

Appl.

Server

Web

Service

HTTP POST SOAP

Security Context I

Security Context II

Main Point: We need security within AND

between security contexts!


43/69

SOAP HTTP SOAP SMTP

Security Context I

Security Context II

Main Point: We need XML validation,

encryption, and authentication between

security contexts!


44/69

Routing

Integrity Validation

Content Checking

AuthenticationAuthorization

XML

ManagementConsole

Design and

Deploy

Security

policies

ID Management

LDAP

PKISingle Sign-On

Reporting

ActivityAlerting

Secure loggingXML


45/69

Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp


46/69

SAML (Security Assertion Markup Language) A XML-based framework (schemas) for the

exchange of authentication and authorizationinformation

A standard message exchange protocol How you ask and receive information

Mainly for integration, up to relying parties todecide to what authentication authority to trust

Assertions can convey information aboutauthentication acts performed by subjects,attributes of subjects, and authorizationdecisions about whether subjects are allowed toaccess certain resources Authentication statements merely describe

acts of authentication that happenedpreviously Specified by OASIS


47/69

XML-based framework for exchangingsecurity information XML-encoded security assertionsXML-encoded request/response protocolRules on using assertions with standard

transport and messaging frameworks SAML & WS-Security allow a SOAP message to

include information about the end-usersauthentication status


48/69

User

Service

User

Service

Domain A Domain B

Authenticationserver A

Authenticationserver B

Using services in B from A?

Authentication at B?

Not acceptable!

Domain A Domain B


49/69

Authentication

server C

Timed

updates

Timed

updates

User

Service

User

Service

Authentication

server A

Authentication

server B


50/69

An assertion is a declaration of fact abouta subject, e.g. a user According to some assertion issues

SAML has three kinds, all related tosecurity:AuthenticationAttributeAuthorization decision

You can extend SAML to make you ownkinds of assertions

Assertions can be digitally signed


51/69

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


52/69

An issuing authority asserts that:Subject Swas authenticated by means Mat time T

Caution: actually checking or revoking ofcredentials is not in the scope of SAML!Password exchangeChallenge-responseEtc.

It merely lets you link back to acts ofauthentication that took place previously


53/69


54/69

Assertion type Description

Authentication Assertion Asserts that subject S wasauthenticated by means M at time T

Attribute Assertion Asserts that subject S is associatedwith attributes A1, A2, with valuesV1,V2,...

Authorization DecisionAssertion

Should the request to subject S foraccess type A be granted toresource R given evidence E


55/69

HTTP

Liberty ID-FF WS-Federation

SAML 1.1 WS-Trust

WS-Security

SOAP

SAML 2.0

Shibboleth

Integrated with Liberty specificationsand the result is SAML 2.0, whichOASIS ratified in March 2006. Backed

by multiple vendors (IBM, BEA, ..)

Backed by Microsoft


56/69

XACML 2.0 and all the associated profiles were approved as OASISStandards on 1 February 2005.

XACML defines three top-level policy elements: , and. The 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 mayform the basic unit of management, and be re-used in multiplepolicies. The element contains a set of elements and a specified

procedure for combining the results of their evaluation. It is the basic unit ofpolicyused by the PDP, and so it is intended to form the basis of anauthorization decision.

Defines algorithms arriving at an authorization decision given theinput rules and policies


57/69

Source: http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

Permit or

deny

Boolean

expression

An operation that shouldbe performed by the

PEP in conjunction with

the enforcement of

authorization decision

Once the SAML authoriz. Has ben madeSOAP msg is

Intercepted SAML query is formed results


58/69

PEP

Policy Enforcement Point Web Service

PDP

Policy Decision Point

PRP

Policy Retrieval Point

PIP

Policy Information Point

Policy Store

(XACML)

PAP

Policy Admin. Point

WS request (SOAP) WS request

SAML Authrz. decision

queryReply

XACML Policy request

Policy (XACML)

Info request

Attribute assertion

Rules are combined:

subjects, resources,

and attributes.

Exported into XACML.

PDP queries attributes

from PIP (time of day,

value, etc.). PIP returns

an attribute assertion.

Once the PDP has all the

relevant information, it evaluates

rules and returns a SAML

authoriz. Assertion

it may be included into the SOAP

message and used by the target WS.

Intercepted. SAML query is formed, results

determine access. Identity info taken from

request. There may be multiple PEPs.


59/69

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 Libertys federated identity and SAML


60/69

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


61/69

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


62/69

Note that both the client and server need to share part of the profile.


63/69

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)


64/69

CardSpace (Microsoft) Multiple identities Interface for identity based authentication and

authorization Identity cards that people can choose Integration with Web sitesConsistent user interfaceMicrosoft plans to implement this

ActiveX, WS-* http://www.identityblog.com/


65/69

Source: http://www.identityblog.com/


66/69

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 anaccount with some identity provider

The user has the choice of selecting a suitable identityprovider

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)


67/69

There are two ways to obtain an OpenID-enabledURL 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 editHTML, one can insert the appropriate OpenID tags in the

HTML code following instructions at the OpenIDspecification.

The second option is to register an OpenID identifier withan identity provider. They offer the ability to register aURL (typically a third-level domain) that will automaticallybe configured with OpenID authentication service.

End User Relying Party(Site) OpenID Provider


68/69

End User Relying Party(Site) OpenID Provider

Visits

OpenID login page

Login using OpenID

Normalization, d iscovery

Association (optional)

Handle

Request authenticationHTTP/Form Redirect

Potential userinteraction

Auth. response

Ver if res onseUser is authenticated


69/69

web services xml ws security architectures

Documents