Toufic Boubez The Future Of S O A Security

24-10-2008

This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com

Founding Sponsors

Platinum Sponsors

Gold Sponsors Silver Sponsors

The Future of SOA
Security
(as far as I can guess)

Toufic Boubez, Ph.D.
Chief Technology Officer
Layer 7 Technologies

tboubez@layer7tech.com
www.layer7tech.com

1

24-10-2008

Agenda

 LOTS of material to cover!!
 No time for Agenda!!

© Toufic Boubez - Layer 7 Technologies

Speaker Introduction

 Current:
 Layer 7 Co-Founder and Chief Technology Officer.
 Co-Editor: WS-Policy W3C Work Group
 Co-Author: WS-Trust, WS-SecureConversation, WS-Federation.
 OASIS WS-RM TC, WS-SX TC
 Books: Building Web Services with Java (12/2001), Java P2P
Unleashed (8/2002).
 Background:
 IBM Lead Architect for Web Services.
 IBM Lead Architect for Web Services Toolkit.
 Co-Author of UDDI V1 specification.
 Technical Chair/Track Chair for the XML Web Services One
Conferences.
 OASIS WS-Security TC, UDDI TC, SAML TC, WS-I Sample Apps
WG
 IBM technical lead for UN/OASIS ebXML.


2

24-10-2008

Drivers for SOA

 Growth and increased productivity:
 Inside the organization, EAI (Enterprise Application
Integration) is essential for increased productivity;
 Outside the organization, integration with partners is
essential for growth.

 Flexibility and agility:
 Easily integrate disparate internal and external resources
and functionalities as needed;
 Easily add and change integrations with business partners;
 Easily add and change IT platforms – avoid vendor lock-in;
 Runtime Configurable Models.

 Just-in-time integration as required:
 Loose coupling as a fundamental architectural principle.


Scenario: Fluid Communities Of Interest

Situation 1
Organization A

Organization B

Organization C
Situation 2


3

24-10-2008

Issues: Runtime Constraints and Capabilities

Situation 1
Organization A

Organization B

Identity Transport
Trust API/Syntax
Security Description
Platform Discovery
Auth/Auth Semantics
Availability Context
Response
Organization C


Theory vs. Practice

 Web Services technology will solve
these problems (will it?)
 In theory, theory and practice are the
same.
 In practice, they're not!

 Two major issues:
 All kidding aside, why would I expose my
backend systems on the Web? Security,
Privacy, Reliability … anyone? anyone?
 So, whatever happened to loose coupling?


4

24-10-2008

Dealing with Security


Fundamentals of Security

ISO 7498-2, 10181

© Layer 7 Technologies

5

24-10-2008

The Present:
Essential Security Requirements for SOA
 SOA brings new requirements:
 Messages may pass through multiple
transports/hops
 Can’t rely on transport security
 Can’t rely on socket continuity
 At any intermediary, certain parts of the
message may need to be processed
 Only encrypt what we need to support the
security policy

Web Services Security © Layer 7 Technologies 11

The Present:
New Security Model for SOA
 SOA necessitates a new security
model:
 Need to decouple security from
transport
 Need to include security information in
the message:
 Credentials or tokens for AuthN/AuthZ
 Encryption of message parts
 Signing of message parts

Web Services Security © Layer 7 Technologies 12

6

24-10-2008

WS-Security
 The security architecture for Web services
 Defines SOAP security headers:
 Tokens:
 Binary Tokens (X.509)
 Username, SAML, Kerberos
 Encryption of message whole or parts
 Signing of message whole or parts
 Unifying standard that brings together a
number of standards efforts, defining how
they are to be used in SOAP messaging
 Eg: W3C XML encryption, c14n, and digital
signatures, OASIS SAML, etc.


<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<wsse:Security>
<wsu:TimeStamp>
Web Service
Server Certificate
<wsse:BinarySecurityToken>

<xenc:EncryptedKey> Reference

<ds:KeyInfo>
Encrypt
<xenc:EncryptedData>

<xenc:DataReference> Web Service
Client Certificate
<ds:Signature> Copy of

<ds:Reference>
<ds:Reference>

Sign

<ds:KeyInfo>

<SOAP-ENV:Body>
<xenc:EncryptedData>


7

24-10-2008

What’s Next:
Dealing with Identity and
Trust

What’s Missing From WS-Security?
 We now have a basic mechanism to secure
SOAP messages on a one-by-one basis.
 Key questions:
 Where do the tokens come from?
 What if I don’t want to propagate identities?
 What I need additional information to make
authorization decisions?
 What if the message exchange pattern requires
more than one request and response pair?
 Missing:
 Portable identity, entitlements, attributes
 Trust, federation, token distribution
 Sessions


8

24-10-2008

The Two Sides of SOA
 SOA brings new challenges:
 The combination of loose coupling and
distributed resources, both fundamental SOA
tenets, are a double edged sword – along with
the potential for much greater IT flexibility and
business agility, they bring the potential for
harder oversight.
 New regulatory environment that requires
much more stringent oversight, monitoring
and enforcement of corporate and IT
governance policies:
 SOX, HIPAA, etc.
 Cross industries: Financial, Health, etc.
 Non-compliance is expensive; also involves personal
responsibility for executives.


Identity Requirements for Policy Compliance
Monitoring
 Identity: Who?
 can access information;
 has accessed information;
 owns information;
 is subject of information;
 has performed action.
 Audit:
 Identity-based audit trail.
 Policy:
 Framework of identity centric corporate security
and privacy rules.
 Trust:
 How to establish loosely coupled trust between
disparate organizations?


9

24-10-2008

The Federation Challenge in Web Services

Islands of Blue’s
Server
Identity
Blue’s
Directory
Green’s Server
Directory
Server
Firewall

Green’s
Client
Alex
Scott
Francis Organization
Blue

Need to share not only
Michelle
authentication and authorization
Dimitri
Organization information, but also identity
Program Green attribute information
X
Big privacy and confidentiality issues…


What Hasn’t Worked in the Past
Issues
• Online access through firewall mazes
• Latency in replication
• People leave, fired, etc

Blue’s
Directory
Green’s Server
Remote
Directory
Directory
Server
Firewall
Access

Organization
Blue

Directory
Synchronization
Michelle
Dimitri
Organization
Program Green
X


10

24-10-2008

What We Really Need is Effective Separation of
Concerns

Authentication
Blue’s
Directory
Green’s Server
Directory
Server
Authorization

Trust

Organization
Blue

Core Requirements
Michelle • Build dynamic trust relationships
Dimitri • Transport the security context so that
Organization authentication and authorization can be
Program Green
X distributed
• Enforce privacy issues
• Time out sessions/global logout


The Mechanism: Global Trust of Local Tokens

Blue’s
Directory
Green’s Server
Identity
Server

Trust

2. Validate token
here according to
trust model
Michelle
Dimitri
1. Acquire trusted token with
Program
statement of authentication (and
X possibly authorization,
entitlements, attributes) in this
security domain

11

24-10-2008

The Standards:
SAML, WS-Trust,
WS-SecureConversation

Next Steps in SOA Security
 Portable, canonical assertions:
 SAML
 Token distribution:
 WS-Trust
 Sessions:
 WS-SecureConversation


12

24-10-2008

What is SAML?
 Security Assertion Markup Language

 “XML standard for exchanging authentication and
authorization data between security domains”
(Wikipedia)

 Cross-platform, XML-based, vendor-neutral
standards for:
 Single Sign-On
 Issuing and communicating trusted identity claims and
associated proofs

 Really multiple standards, assertions and various
protocols and profiles


SAML Assertions: What’s inside?
 A SAML assertion can have:

 Subject: who am I talking to (or about)?
 Authentication Statements: how was the Subject
authenticated?
 Attribute Statements: what attributes does the
Subject have?
 Authorization Decision Statements: what is the
Subject permitted to do?
 Signature: who is making the statements about the
Subject, and how can you decide whether to trust them?
 Unfortunately they're all optional, but in practice SAML
Assertions will conform fairly closely to a few
stereotypes.


13

24-10-2008

What is WS-Trust?
 Specifies an abstract protocol for exchanging
security tokens with a Security Token Service
(STS)
 Some examples of security tokens:
 UsernameTokens (login plus password or digest)
 SAML Assertions
 Encrypted symmetric keys (or partial keys)
 Security Context Tokens (WS-SecureConversation
sessions)
 WS-Trust itself provides no concrete examples;
use cases have come from:
 Informal but widespread consensus:
 Issuing SAML Assertions
 Other standards efforts:
 WS-SecureConversation / WS-SecureExchange


WS-Trust and SAML: Typical Use Case
 Requester sends UsernameToken with username and
password to Identity Provider STS in
<RequestSecurityToken> message.

 STS authenticates credentials, issues signed SAML
Assertion containing AuthenticationStatement, sends
it back in <RequestSecurityTokenResponse>

 Requester caches SAML Assertion, includes it in SOAP
Security Header of outbound messages

 Recipient verifies assertion signature, validates that
signer is a trusted SAML issuer

 SAML Assertion can be re-used until it expires


14

24-10-2008

<SOAP-ENV:Envelope>

<SOAP-ENV:Header>

<SAML:Assertion>

Statement 1
Issuing
Authority

…
signature
covers
assertion and
binds
Statement n statements
to Subject’s
public key

<SubjectConfirmation>
<KeyInfo>

<ds:Signature>
Issuing
Authority

<ds:Signature> The key used in Subject’s signature Subject signs
across the message body is the analogue Subject its message
of the one bound into the assertion.

<SOAP-ENV:BODY>


The Mechanism: Global Trust of Local Tokens

Blue’s
Directory
Green’s Server
Identity
Server

SAML
Trust

SAML

2. Validate token
here according to
trust model
Michelle
Dimitri
1. Acquire trusted token with
Program
statement of authentication (and
X possibly authorization,
entitlements, attributes) in this
security domain

15

24-10-2008

WS-Trust: Typical Token Validation Request
<soapenv:Envelope>
<soapenv:Body>
<wst:RequestSecurityToken>
<wst:Base> Incoming token
<wsse:UsernameToken>
<wsse:Username>testuser</wsse:Username>
<wsse:Password Type="...#PasswordText">pass</wsse:Password>
</wsse:UsernameToken>
</wst:Base>
<wst:Issuer>
<wsa:Address>http://myemployer.example.com/</wsa:Address>
</wst:Issuer>
Issuer of Incoming token
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://samlpart.com/sso</wsa:Address>
</wsa:EndpointReference>
Scope of intended use
</wsp:AppliesTo>
<wst:RequestType>...Validate</wst:RequestType>
</wst:RequestSecurityToken>
</soapenv:Body>
</soapenv:Envelope>
What the STS should do with Incoming token


WS-Trust: Typical Token Response
<soapenv:Envelope>
<soapenv:Body>
<wst:RequestSecurityTokenResponse>
<wst:RequestedSecurityToken>
<saml:Assertion>
<ds:Signature/>
</saml:Assertion>
</wst:RequestedSecurityToken> Returned Token
<wst:RequestedTokenReference>
<wss:KeyIdentifier ValueType="saml:Assertion">
Assertion-uuidd0dad954-0101-e072-018a-b935cd071747
</wss:KeyIdentifier>
</wst:RequestedTokenReference>
<wst:Status>

<wst:Code>http://schemas.xmlsoap.org/ws/2004/04/security/trust/status/valid</w
WS-Security plumbing
st:Code>
</wst:Status>
</wst:RequestSecurityTokenResponse>
</soapenv:Body>
</soapenv:Envelope>


16

24-10-2008

WS-SecureConversation
 WS-Security provides security on a message by
message basis.
 Frequently, there is a need to exchange
multiple messages between consumer and
provider in a single conversation.
 A Security Context is a convenient mechanism
to provide a form of a session, without the
need to generate new keys for every message.
 WS-SC provides a mechanism to generate and
exchange a SecurityContextToken.
 The SCT can be used until it expires.
 SCT’s are requested and issued through specific
WS-Trust bindings.


What About Loose
Coupling?


17

24-10-2008

The Potential of Web Services – A Governance
Nightmare?
SOAP over http
SOAP over http XML encryption
AD based ACL Digital Signature
Text logging Guaranteed QoS
Inventory getLevel Non-repudiation audit logging

update

Procurement
SOAP over https
LDAP based ACL
Text logging
order

SOAP over http
XML encryption
Digital Signature
Guaranteed QoS
Non-repudiation audit logging


How to Introduce Flexibility into a System
 Software engineering principles:
 Decouple the variable part of an
implementation from the invariant part.
 Invariant is the business functionality of
the Web service
 Variable is the layers of policy
 Introduce flexibility into the system
through the use of policies:
 Decouple the policy part of Web services
from the business logic part.


18

24-10-2008

A Simple Analogy: Audio Systems

 Monolithic, proprietary  RCA Jack: standard
design interfaces and data
format; component
 Fixed architecture and design
capabilities  Flexible architecture
 Vulnerable to  Future-proof
technology change  Vendor-neutral
 Single-source vendor  Competition drives
 Expensive prices down

One Step Further: Professional Sound Systems

 Abstract out input  Abstract out requester
devices and output origination points and
devices. provider endpoints.
 Syndicate a variety of  Syndicate a variety of
inputs to a variety of services to a variety
outputs. of consumers.
 Complete control over  Complete control over
input and output provider and
parameters. consumer policies.


19

24-10-2008

From Business Drivers To Web Services: Reusable
Components Framework

Business Drivers (Inputs)
-Revenue/Profit Web Services
Business Services
-Market share -getInventoryBySKU
-Get Inventory Levels
-Agility -getInventoryByPC
-Inventory Updates
-Forecasting
Business Services Web Services
Business Service Types -Get Customer Account -removeSKUItems
-Inventory -Inventory Updates -addSKUItems
-CRM -Forecasting
-HR Web Services …
-Accounting Business Services…
-…

Registry (MetaData)

Reusable Business Components Framework


Corporate And Architecture Drivers: Runtime Policy
Framework

Corporate Policy Drivers (Inputs) Corporate Architectural Drivers (Inputs)
-Governance -Flexibility and Reuse
-Compliance -Platform Independence
-Security -Integration with existing infrastructure
-Security, Scalability, Availability, Performance

Security SLA Reliability
-WS-Security -Response Time -WS-RM
-X509TokenProfile -Availability Platform
-SAMLTokenProfile -IP Range, ToD -Load Balancing
-XML Encryption -Throughput Limits -WS-Addressing
-XML Signatures -Non-repudiation
Transport Threat Protection
Message X-Form
-HTTP -Schema Validation
-Versioning
-TLS -Virus Scanning
-Localization
-JMS -Attachments
-DS (ACORD, FIX)

Registry (MetaData)

Runtime Policy Framework


20

24-10-2008

Joining The Two Frameworks:
Policy Driven SOA


Managed Communications Infrastructure



Decoupling Policy in Practice:
The Policy Enforcement Point
WSDL
Document

Policy
Enforcement Point

Policy
Document

Web Services
Web Services
Policy Provider
Consumer
Registry


21

24-10-2008

Decoupling Policy in Practice:
The Policy Application Point
Policy WSDL
Application Document
Point
Policy
Conforming
SOAP Policy
Request
Enforcement Point

Policy
Document

Web Services
Web Services
Policy Provider
Consumer
Registry

Signed
Policy
Document


PEPs in the Architecture

Firewalls
(Perimeter PEPs)
Service Service Service
External
Service Endpoint Endpoint Endpoint
PEP PEP PEP

External
Service
Centralized Intermediary Intermediary
PEP PEP PEP
External
Service
Endpoint Endpoint Endpoint
DMZ PEP PEP PEP
External
Service Service Service Service

Courtesy: Anne Thomas Manes, Burton Group

22

24-10-2008

Main WS-Policy Specifications
 WS-Policy
 Assertion framework to describe requirements and
capabilities of a service, e.g. transport bindings, QoS
requirements, etc.
 Sometimes known as WS-PolicyFramework.
 WS-PolicyAssertions
 A set of common message policy assertions related to
language preferences, versioning and predicates.
 WS-SecurityPolicy
 Assertions, using the WS-Policy format, relevant to WS-
Security.
 Model for other types of WS-*Policy to be defined by
interest groups.
 WS-PolicyAttachment
 How to associate policy assertions to Web services
descriptions in WSDL and UDDI


WS-Policy Example

<wsp:Policy xmlns:wsse="..." xmlns:wssx="...">
<wsp:ExactlyOne>
<wsp:All wsp:Usage="wsp:Required">
<wsse:SecurityToken>
<wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType>
</wsse:SecurityToken>
<wssx:Privacy />
</wsp:All>
<wsp:All wsp:Usage="wsp:Required">
<wsse:SecurityToken>
<wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
</wsse:SecurityToken>
<wssx:Audit />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>


23

24-10-2008

Conclusions
 Security, Identity are becoming increasingly
important as organizations move to SOA
 Cross-domain, distributed services
 Increased regulations
 Move from transport-based to message-based
security necessitates a new set of standards:
 WS-Security
 SAML
 WS-Trust
 WS-Policy
 Loose coupling necessitates separating business
logic from policy infrastructure:
 The emergence of Policy Enforcement Points


Some References on WS-*
 WS-Security:
 http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wss
 WS-SecureExchange (WS-SX):
 http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=ws-sx
 W3C WS-Policy Workgroup
 http://www.w3.org/TR/WS-Policy/

"Policy-It's More Than Just Security“,
T. Boubez, S. Morrison, M. Hondo, XML Journal
 http://www.sys-con.com/xml/article.cfm?id=772


24

24-10-2008

Thanks!
 Thank you very much for making it
through!
 Email questions or comments or
presentation requests to:
 tboubez@layer7tech.com


25

Toufic Boubez The Future Of S O A Security

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (12)

Semelhante a Toufic Boubez The Future Of S O A Security

Semelhante a Toufic Boubez The Future Of S O A Security (20)

Mais de SOA Symposium

Mais de SOA Symposium (20)

Último

Último (20)

Toufic Boubez The Future Of S O A Security