soa, interoperability and security

SOA, Interoperability

and Security

All roads lead to web services

security

Nataraj Nagaratnam, Ph.D.,

IBM Distinguished Engineer

Chief Architect, Identity and SOA Security, Tivoli, Software Group, IBM

[email protected]

Agenda

• Service Oriented Architecture and Interoperability

– Role of Web Services

• SOA Security Considerations

• Web Services Security

– Standards Roadmap

– Message security

– Policy

– Trust, Authorization

10/23/2007 Template Documentation 3

SOA and Interoperability

What is SOA?… a service?

A repeatable business task –

e.g., check customer credit;

open new account

… service oriented architecture (SOA)?

An IT architectural style that supports

integrating your business as linked

services


What is the SOA model? Business Componentization

Re-defining today’s monolithic enterprise

processes as a set of standardized

modular business process components

Business Componentization

Re-defining today’s monolithic enterprise

processes as a set of standardized

modular business process components

Service Oriented Architecture

An IT model which mirrors the interaction

of business components through a set of

IT applications implemented as real-time

services that interact dynamically

Service Oriented Architecture

An IT model which mirrors the interaction

of business components through a set of

IT applications implemented as real-time

services that interact dynamically

Business

components

SOA application

components *

Web Services

A set of vendor neutral and platform

agnostic standards that can be used to

define how SOA components interact

Web Services

A set of vendor neutral and platform

agnostic standards that can be used to

define how SOA components interact

WS Protocols (XML, SOAP, WSDL, UDDI) provide an interface toolkit for components

Business components

SOA components

Components interfaces

Web Services protocols* Each SOA application component may be made up of multiple applications

Business

Processes

Quality of

Service

Description

Messaging

Business Process Execution LanguageFor Web Services (BPEL4WS)

SecurityReliability ManagementTransactions

Web Services Description Language (WSDL)

Simple Object Access Protocol (SOAP)

Extensible Markup Language (XML)

Other Protocols Other Services

Web Services – a Simple View

WS-* Architectural Principles• Message orientation

– Using only messages to communicate between services

• Protocol composability– Use protocol building blocks in nearly any combination.

• Autonomous services – Independent endpoints

• Managed transparency– Controlling what is externally visible

• Protocol-based integration – Coupling via wire artifacts only.

SOA – Security considerations


Security Considerations for SOA• Entities/Identities – users, services

�Services have identities

� Identities and/or credentials are propagated across services

�Users and services are now subject to the same security controls

• Organizational/enterprise boundaries

�Perimeter is obscure

� Identities are managed across boundaries

�Trust relationships are established across boundaries

• Composite applications

�Ensuring proper security controls are enacted for each service and when used in combination

• Greater focus on data/information

�Protecting data at transit and at rest

�Apply consistent protection measures

�Access to data by applications and services

• Governance, Risk, and Compliance

�Auditing ie. entity identification to specific transactions


SOA Security – Reference Model

Business Security Services

Identity &

Access

Data Protection, Privacy

& Disclosure Control

Secure Systems

& Networks

Compliance &

Reporting

Trust

Management

Sec

uri

ty P

oli

cy I

nfr

astr

uc

ture

Authentication

Services

IT Security Services

Authorization

Services

Audit

Services

Identity Services

Integrity

Services

Non-repudiation

Services

Confidentiality

Services

Security Enablers

Go

ve

rna

nce

an

d R

isk M

an

ag

em

en

t

Po

lic

y

Ma

na

ge

me

nt

Web Services Security

Interoperable security enablers and services

• Message security

–Integrity, Confidentiality, Identity propagation

• Policy constraints, requirements

–Constraints, Authorization, privacy, ..

• Security services

–Standardized virtualized security services

Standards Summary: Web Services Security

Message SecurityMessage Security

SecuritySecurityPolicyPolicy

SecureSecureConversationConversation

TrustTrust

FederationFederation

PrivacyPrivacy

AuthorizationAuthorization

SOAP MessagingSOAP Messaging

Message protection


Message Processing Requires New Layers of Security

WS-Security

SenderSender ReceiverReceiverIntermediaryIntermediary IntermediaryIntermediary

……

WS-Security• Defines a framework for building security protocols

– Integrity

– Confidentiality

– Propagation of security tokens

• Framework designed for end-to-end security of SOAP messages

– From initial sender, through 0-n intermediaries to ultimate receiver

• Leverages existing XML security specs

– XMLDSIG for integrity

– XMLENC for confidentiality

• Provides constructs for transmitting security tokens

– Supports XML and binary tokens

WS-Security

• WS-Security does provide:

– Message level security

– “Improved SSL”

– Security at lower/network

layer

– Transmission security

– Message authentication

– Message confidentiality

– Message integrity

• WS-Security does NOT provide:

– Application level security

– Enterprise security

– Authentication mechanisms

– Authorization security

– Intrusion detection

– Identity management

– Security Architecture

– Network Security

– Anti-Virus protection

What are Security Tokens?• Examples include

– Username token

– X509 Certificate

– Kerberos ticket

– REL license

– SAML assertion

• Represent claims about

– Identity

– Capabilities

– Privileges

• Message claims to be from Alice

– Specified using Alice's X509

certificate

• Proof is based on Alice's private key

– Signing part of the message

with her private key proves that she knows the key and

is therefore Alice

– Specifically, that the signed

parts are from Alice

Web Services message transmission

Soap Header

Message Header and Routing

Security Content

Signature

Actual signed content

Message Body

Soap EnvelopeSoap Envelope

Security Token

WS Security• Terminology:

– Claim - A claim is a statement that a client makes (e.g. name, identity, key, group, privilege, capability, etc).

– Security Token - A security token represents a collection of claims.

– Signed Security Token - A signed security token is a security token that is asserted and cryptographically endorsed by a specificauthority (e.g. an X.509 certificate or a Kerberos ticket).

– Proof-of-Possession - The proof-of-possession information is data that is used in a proof process to demonstrate the sender's knowledge ofinformation that SHOULD only be known to the claiming sender of a security token.

– Integrity - Integrity is the process by which it is guaranteed that information is not modified in transit.

– Confidentiality - Confidentiality is the process by which data is protected such that only authorized actors or security token owners can view the data

– Digest - A digest is a cryptographic checksum of an octet stream.

– Signature - A signature is a cryptographic binding of a proof-of-possession and a digest. This covers both symmetric key-based and public key-based signatures. Consequently, non-repudiation is not always achieved.

– Attachment - An attachment is a generic term referring to additional data that travels with a SOAP message, but is not part of the SOAP Envelope.

WS Security Capabilities Summary

• Message Security Model

– Security Tokens MAY be bound to messages

• Message Protection

– Message Integrity – attained by using XML Signatures with Security Tokens

– Message Confidentiality – attained by using XML Encryption with Security Tokens

• WS Security Standard allows:

– Encryption/Signing of:• Body

• Body Elements

• Header

• Attachments

WS Security Message Example

(001) <?xml version="1.0" encoding="utf-8"?>(002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">(003) <S:Header>(004) <m:path xmlns:m="http://schemas.xmlsoap.org/rp/">(005) <m:action>http://fabrikam123.com/getQuote</m:action>(006) <m:to>http://fabrikam123.com/stocks</m:to>(007) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>(008) </m:path>

First two lines start SOAP message

Lines 004 to 008 define how to route this message

Message example with a username security token (1 of 3):


(009) <wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">

(010) wsse:UsernameToken Id="MyID">(011) <wsse:Username>Zoe</wsse:Username>(012) </wsse:UsernameToken>(013) <ds:Signature>(014) <ds:SignedInfo>(015) <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

(016) <ds:SignatureMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>

(017) <ds:Reference URI="#MsgBody">(018) <ds:DigestMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

(019) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>(020) </ds:Reference>

Line 009: Start of Security header

Lines 010 to 012 specify the security token


Lines 013 to 028 specify a digitalsignature – this example uses a signature based on the security token, this is NOT a recommended signature scheme


(021) </ds:SignedInfo>(022) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>(023) <ds:KeyInfo>(024) <wsse:SecurityTokenReference>(025) <wsse:Reference URI="#MyID"/>(026) </wsse:SecurityTokenReference>(027) </ds:KeyInfo>(028) </ds:Signature>(029) </wsse:Security>(030) </S:Header>(031) <S:Body Id="MsgBody">(032) <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">

QQQ</tru:StockSymbol>

(033) </S:Body>(034) </S:Envelope>

Lines 031 to 033 contain the body of the SOAP message


Interoperable secure messages

across SOA environment

WS-Security based messages:

Tokens, Signature, Encrypted elements

IBM

WebSphere

IBM WebSphere

DataPower

Trust model: trust, authentication

and identity propagation

WS-Trust• Defines how to broker trust relationships

– Some trust relationship has to exist a priori

• Defines how to exchange security tokens

• Defined as an interface specification for a Security

Token Service

• Anyone can issue tokens (be a Security Token

Service)

Getting Tokens• A RequestSecurityToken message is sent to the trust

service

• It responds with a RequestSecurityTokenResponse

– Contains required security token and associated details (e.g. proof)

• Example

– I want to have secure communication with you

– I ask the trust service for a token to allow me to talk to you

– The trust service sends two copies of a secret key

• One encrypted for me (proof token)

• One encrypted for you (requested token)

Example

11111111U/P

T1

P1

TrustTrustTrustTrustTrustTrustTrustTrust

22222222 T2

P2

T1

33333333

T2

Trust

Trust

Trust

Trust

Trust

Trust

Trust

Trust

T#

P#

Security TokenSecurity Token

Proof tokenProof token

Identity mediation using WS-TrustTivoli Federated Identity Manager

ESB

Firewall

Firewall

Tivoli Federated Identity Manager

DataPower

Challenge mechanism

Request TokenRequest Token

Issue ChallengeIssue Challenge

Respond to ChallengeRespond to Challenge

Issue TokenIssue Token

Other Token Characteristics• Requester can specify various required

characteristics of the security token

– Key type, size

– Delegation constraints

– …

• Trust service can then indicate those characteristics in the response

– May indicate anything it thinks important

Persisted Context

SCT

Farm Context

SCT

WS-SecureConversation• WS-Security provides for single message security

• Nodes will often want to exchange more than one

message

– Specifying new symmetric keys for each message is tedious, verbose, and inefficient

• WS-SecureConversation defines mechanisms to

address this

WS-SecureConversation• Participants establish a shared context

– Context contains keys/secrets and other

information

– Can be stateless (state embedded in security

context token)

• Context established multiple ways

– Using token exchange

– Having one party create the context

– Through negotiation

Policy

Policy Framework

PolicyPolicy

PolicyPolicyAttachmentAttachment

PolicyPolicyAssertionsAssertions

WSDLWSDL

WS-Policy• Framework for expressing Web service

capabilities and requirements

–Security

–Transactions

–Reliable messaging

–Transports

–...

WS-Policy Model• Policy: collection of alternatives; pick one

• Alternative: collection of assertions; do all

• Assertion: domain-specific behavior

–Strongly typed

–Arbitrary parameters to behavior

WS-Policy Expressions• May represent a policy in a compact form

–Nest operators

• All distributes over ExactlyOne

–Assertion/@wsp:Optional=‘true’

• An alternative with and an alternative without

• Simplification of prior @wsp:Usage=‘xs:QName’

–Policy reference to reuse common expression

• Included as is where referenced

WS-Policy Intersections

• Do two Web service endpoints have compatible policy?

–At design time to “wire together” compatible

services

–At runtime to select compatible options

• Two alternatives are compatible if they at least have the same assertion types

WS-Policy Runtime Intersections

WS-PolicyAttachment• Associate policy with WSDL constructs

– Interface-wide policy, e.g.,

• SOAP version

• Transports (and addresses)

• Which token to use when signing messages

• Which version of transactions (if any)

– Message policy, e.g.,

• Which parts of this message to sign

• Whether this message is part of a transaction

WS-SecurityPolicy• A set of policy assertions related to

concepts defined by other WS-Sec* specs

• Allows participants to specify

– Token types

– Whether integrity and/or confidentiality are

required

– Algorithms for the above

– Which message parts need signing/encrypting

WS-SecurityPolicy Example<wsp:Policy><sp:SymmetricBinding><wsp:Policy><sp:ProtectionToken><wsp:Policy><sp:KerberosV5APREQToken

sp:IncludeToken=".../IncludeToken/Once" /></wsp:Policy>

</sp:ProtectionToken><sp:SignBeforeEncrypting /><sp:EncryptSignature />

</wsp:Policy></sp:SymmetricBinding><sp:SignedParts><sp:Body/><sp:Header

Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>

</sp:SignedParts><sp:EncryptedParts><sp:Body/>

</sp:EncryptedParts></wsp:Policy>

Federation

WS-Federation• “Single Sign-On” access across trust

domains using identities from the different domains

• WS-Federation defines a model for this building on the WS-* security specifications:–Model for trust

–Sign out messages

–Attribute service

–Pseudonym service

Federation –Using Tivoli Federated Identity Manager

Web Access /Web SSO

Benefits Service Billing ServicePortal

Service

Web SSO Web SSO Web SSO

WS-Security/WS-Federation/SAML

Partners using

Microsoft®

Partners using

Liberty

Partners using

SAML

Third-party User

Partner

Third Party

Third-Party Access

Tivoli FederatedIdentity Manager

User

Federated Access

Direct Access

WS-Federation/SAML

Authorization

Authorization (WS-Trust profile)

• Authorization service that renders authorization decision and can return entitlements

• Authorization attributes could be part of token issue

• Built on WS-Trust

• Now published as part of WS-Federation spec

Secure, Reliable, Transacted Web Services

Service Composition

ComposableService

Assurances

Description

Messaging

Transports

BPEL4WS

Security

XSD, WSDL, UDDI, Policy, MetadataExchange

XML, SOAP, Addressing

HTTP, HTTPS, SMTP

ReliableMessaging

Transactions

From joint IBM/MSFT WS Whitepaper at From joint IBM/MSFT WS Whitepaper at

http://msdn.microsoft.com/webservices/default.aspx?pull=/libraryhttp://msdn.microsoft.com/webservices/default.aspx?pull=/library/en/en--us/dnwebsrv/html/wsoverview.aspus/dnwebsrv/html/wsoverview.asp

Importance of Composition• Everything works in combination

– Ex: Transaction context works over a reliable connection

– Ex: Participants use WS-Security to secure transactions (for

all types participants)

• Not "reinventing the wheel" for every stack

– Code reuse, lower costs, faster time to market

– Ex: all resources named using WS-Addressing

• The overall system is more stable

– Changes don't percolate up the stack

– Ex: By using WS-Security, Federation supports all tokens,

including future ones

Composable Headers

Addressing

<S:Envelope … ><S:Header>

<wsa:ReplyTo><wsa:Address>http://business456.com/User12</wsa:Address>

</wsa:ReplyTo><wsa:To>http://fabrikam123.com/Traffic</wsa:To><wsa:Action>http://fabrikam123.com/Traffic/Status</wsa:Action>

<wssec:Security> <wssec:BinarySecurityToken

ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary">

dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD</wssec:BinarySecurityToken>

</wssec:Security><wsrm:Sequence>

<wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier><wsrm:MessageNumber>10</wsrm:MessageNumber>

</wsrm:Sequence></S:Header><S:Body>

<app:TrafficStatusxmlns:app="http://highwaymon.org/payloads">

<road>520W</road><speed>3MPH</speed></app:TrafficStatus>

</S:Body></S:Envelope>

Security

Reliability

IBM Product Support• WebSphere Application Server 5.0

– Supported WS-Security input spec as a technology preview

– WAS 5.02 Supported the first WSS TC committee draft as a

partial implementation

• WebSphere Application Server 5.1

– Increased support for the first WSS TC committee draft

• WebSphere Application Server 6.0

– Supports full OASIS WSS TC Standard v1.1

• Tivoli Federated Identity Manager

– WS-Security support

– WS-Trust support

– WS-Federation support

Standards Summary: Web Services Security

Message SecurityMessage Security

SecuritySecurityPolicyPolicy

SecureSecureConversationConversation

TrustTrust

FederationFederation

PrivacyPrivacy

AuthorizationAuthorization

SOAP MessagingSOAP Messaging

References (1 of 4)

• OASIS WSS TC Homepage– http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

• Web Services Security: SOAP Message Security– http://www.oasis-open.org/committees/download.php/5941/oasis-

200401-wss-soap-message-security-1.0.pdf

• Web Services Security: Username Token Profile– http://www.oasis-open.org/committees/download.php/5942/oasis-

200401-wss-username-token-profile-1.0.pdf

• Web Services Security: X.509 Certificate Token Profile– http://www.oasis-open.org/committees/download.php/5943/oasis-

200401-wss-x509-token-profile-1.0.pdf

• Schema Files– http://www.oasis-open.org/committees/download.php/5076/oasis-

200401-wss-wssecurity-secext-1.0.xsd.xsd

– http://www.oasis-open.org/committees/download.php/5075/oasis-200401-wss-wssecurity-utility-1.0.xsd.xsd

References (2 of 4)

• OASIS WSS TC Call for participation & Original Charter– http://lists.oasis-open.org/archives/wss/200207/msg00000.html

• OASIS WSS TC Revised Charter – after first TC meeting– http://lists.oasis-open.org/archives/members/200209/msg00007.html

• OASIS Announcement of public review phase for WS-Security– http://lists.oasis-open.org/archives/members/200309/msg00011.html

• OASIS Announcement of WSS voting as a 1.0 standard– http://lists.oasis-open.org/archives/members/200403/msg00014.html

• Original DeveloperWorks posting of WS-Security,Roadmap & Addendum– http://www-106.ibm.com/developerworks/webservices/library/ws-

secure/– http://www-106.ibm.com/developerworks/webservices/library/ws-

secmap/

– http://www-106.ibm.com/developerworks/library/ws-secureadd.html

• WS-Security License from IBM– http://www.ibm.com/ibm/licensing/977Q/2112.shtml

• WS-Security License from Microsoft– http://msdn.microsoft.com/webservices/wss_license.aspx

References (3 of 4)• OASIS WSS TC Disposition of public review/comments

– http://lists.oasis-open.org/archives/wss/200401/msg00157.html


• OASIS WSS TC Notes sent to OASIS at submission time– http://lists.oasis-open.org/archives/wss/200402/msg00040.html– http://www.oasis-

open.org/apps/org/workgroup/wss/download.php/5334/submission-notes.pdf

• Statements of implementation– http://lists.oasis-open.org/archives/wss/200402/msg00022.html


– http://lists.oasis-open.org/archives/wss/200402/msg00023.html – http://lists.oasis-open.org/archives/wss/200402/msg00029.html

– http://lists.oasis-open.org/archives/wss/200402/msg00024.html – http://lists.oasis-open.org/archives/wss/200402/msg00026.html



References (4 of 4)

• OASIS WSS TC Public review comments archive

– http://lists.oasis-open.org/archives/wss-comment/

• OASIS WSS TC Latest “issues list” as of 3/23/2004

– http://www.oasis-open.org/committees/download.php/6047/wss-issues-36.htm

soa, interoperability and security

Documents