You are on page 1of 65

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 natarajn@us.ibm.com

Agenda
Service Oriented Architecture and Interoperability
Role of Web Services

SOA Security Considerations Web Services Security


Standards Roadmap Message security Policy Trust, Authorization

SOA and Interoperability

10/23/2007

Template Documentation

What is SOA?
a service? service oriented architecture (SOA)?

A repeatable business task e.g., check customer credit; open new account

An IT architectural style that supports integrating your business as linked services

What is the SOA model?


Business Componentization
Re-defining todays monolithic enterprise processes as a set of standardized modular business process components

Business 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

SOA application components *

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 5

10/23/2007

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

Template Documentation

Web Services a Simple View


Business Processes Quality of Service Description Messaging
Business Process Execution Language For Web Services (BPEL4WS)

Reliability

Transactions

Management

Security

Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Extensible Markup Language (XML) Other Protocols Other Services

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
10/23/2007 Template Documentation 9

SOA Security Reference Model


Governance and Risk Management Business Security Services Security Policy Infrastructure
Compliance & Reporting Identity & Access Data Protection, Privacy & Disclosure Control Trust Management Non-repudiation Services Secure Systems & Networks

Policy Management

IT Security Services
Identity Services Confidentiality Services Authentication Services Integrity Services Authorization Services Audit Services

Security Enablers

10/23/2007

Template Documentation

10

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


Secure Conversation Security Policy Federation Trust Message Security SOAP Messaging Authorization Privacy

Message protection

Message Processing Requires New Layers of Security

10/23/2007

Template Documentation

15

WS-Security
Sender Intermediary Intermediary Receiver

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

Represent claims about


Identity Capabilities Privileges

Web Services message transmission


Soap Envelope Soap Header Message Header and Routing Security Content Security Token Signature Actual signed content Message Body

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 of information 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


Message example with a username security token (1 of 3):
First two lines start SOAP message (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/"> Lines 004 to 008 define how to (005) <m:action>http://fabrikam123.com/getQuote</m:action> route this message (006) <m:to>http://fabrikam123.com/stocks</m:to> (007) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id> (008) </m:path>

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


(009) (010) (011) (012) (013) (014) (015)

WS Security Message Example

(016)

(017) (018)

(019) (020)

<wsse:Security Line 009: Start of Security header xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> wsse:UsernameToken Id="MyID"> Lines 010 to 012 specify the security token <wsse:Username>Zoe</wsse:Username> </wsse:UsernameToken> <ds:Signature> <ds:SignedInfo> Lines 013 to 028 specify a digital signature this example uses a <ds:CanonicalizationMethod signature based on the security Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> token, this is NOT a recommended signature scheme <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> <ds:Reference URI="#MsgBody"> <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue> </ds:Reference>

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


(021) (022) (023) (024) (025) (026) (027) (028) (029) (030) (031) (032)

WS Security Message Example

</ds:SignedInfo> <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#MyID"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header> <S:Body Id="MsgBody"> <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> Lines 031 to 033 contain the body of the SOAP message QQQ </tru:StockSymbol> (033) </S:Body> (034) </S:Envelope>

Interoperable secure messages across SOA environment


IBM WebSphere DataPower IBM WebSphere

WS-Security based messages: Tokens, Signature, Encrypted elements

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
Trust

U/P

P1 T1

T2 P2

3
T2 T# P#

Trust
Security Token Proof token

T1

Identity mediation using WS-Trust Tivoli Federated Identity Manager

Firewall

Tivoli Federated Identity Manager

ESB

DataPower

Firewall

Challenge mechanism

Request Token Issue Challenge Respond to Challenge Issue Token

Requester can specify various required characteristics of the security token


Key type, size Delegation constraints

Other Token Characteristics

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
Policy Attachment Policy WSDL Policy Assertions

WS-Policy
Framework for expressing Web service capabilities and requirements
Security Transactions Reliable messaging Transports

...

Policy: collection of alternatives; pick one Alternative: collection of assertions; do all Assertion: domain-specific behavior
Strongly typed Arbitrary parameters to behavior

WS-Policy Model

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
Third-Party Access
Partner

Partners using Microsoft


Third Party

Federated Access

Partners using SAML

Third-party User
WS-Security/WSFederation/SAML Direct Access

WS-Federation/SAML

Partners using Liberty

Tivoli Federated Identity Manager


Web Access / Web SSO

User Web SSO Web SSO Billing Service Web SSO Portal Service

Benefits Service

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


BPEL4WS Service Composition Composable Service Assurances Description Messaging Transports

Security

Reliable Messaging

Transactions

XSD, WSDL, UDDI, Policy, MetadataExchange XML, SOAP, Addressing HTTP, HTTPS, SMTP

From joint IBM/MSFT WS Whitepaper at http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-

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:TrafficStatus xmlns: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


Secure Conversation Security Policy Federation Trust Message Security SOAP Messaging Authorization Privacy

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/oasis200401-wss-soap-message-security-1.0.pdf

Web Services Security: Username Token Profile


http://www.oasis-open.org/committees/download.php/5942/oasis200401-wss-username-token-profile-1.0.pdf

Web Services Security: X.509 Certificate Token Profile


http://www.oasis-open.org/committees/download.php/5943/oasis200401-wss-x509-token-profile-1.0.pdf

Schema Files
http://www.oasis-open.org/committees/download.php/5076/oasis200401-wss-wssecurity-secext-1.0.xsd.xsd http://www.oasis-open.org/committees/download.php/5075/oasis200401-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/wssecure/ http://www-106.ibm.com/developerworks/webservices/library/wssecmap/ 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 http://lists.oasis-open.org/archives/wss/200311/msg00044.html

OASIS WSS TC Notes sent to OASIS at submission time


http://lists.oasis-open.org/archives/wss/200402/msg00040.html http://www.oasisopen.org/apps/org/workgroup/wss/download.php/5334/submissionnotes.pdf

Statements of implementation
http://lists.oasis-open.org/archives/wss/200402/msg00022.html http://lists.oasis-open.org/archives/wss/200402/msg00027.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 http://lists.oasis-open.org/archives/wss/200402/msg00025.html http://lists.oasis-open.org/archives/wss/200402/msg00028.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

You might also like