The Future of SOA Security

24-10-2008

1

Founding Sponsors

This Presentation Courtesy of the

International SOA Symposium

October 7-8, 2008 Amsterdam Arena

www.soasymposium.com

[email protected]

Gold Sponsors

Platinum Sponsors

Silver Sponsors

The Future of SOA Security

(as far as I can guess)

Toufic Boubez, Ph.D.Chief Technology OfficerLayer 7 Technologies

[email protected]

24-10-2008

2

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.


24-10-2008

3

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


Organization A

Organization B

Organization C

Situation 1

Situation 2

24-10-2008

4

Issues: Runtime Constraints and Capabilities


Organization A

Organization B

Organization C

Situation 1

Identity

Trust

Security

Platform

Auth/Auth

Availability

Response

Transport

API/Syntax

Description

Discovery

Semantics

Context

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?


24-10-2008

5

Dealing with Security


© Layer 7 Technologies

ISO 7498-2, 10181

Fundamentals of Security

24-10-2008

6

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

24-10-2008

7

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>

<SOAP-ENV:Body>

<wsse:Security>

<ds:Signature>

<wsu:TimeStamp>

<ds:Reference>

<ds:Reference>

Web Service Client Certificate

Web Service Server Certificate

<xenc:EncryptedData>

Reference

Encrypt

<xenc:EncryptedKey>

<ds:KeyInfo>

<xenc:EncryptedData>

<xenc:DataReference>

<wsse:BinarySecurityToken>

<ds:KeyInfo>

Sign

Copy of

24-10-2008

8

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


24-10-2008

9

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?


24-10-2008

10

The Federation Challenge in Web Services


Alex

Scott

Francis

Firewall

Blue’s Server

Blue’s Directory Server

Organization Green

Michelle

Dimitri

Program X

Green’s Directory Server

Organization Blue

Green’s Client

Islands of Identity

Need to share not only authentication and authorization

information, but also identity attribute information

Big privacy and confidentiality issues…

What Hasn’t Worked in the Past


Firewall


Organization Green

Michelle

Dimitri

Program X


Organization Blue

Remote Directory Access

Directory Synchronization

• Online access through firewall mazes

• Latency in replication

• People leave, fired, etc

Issues

24-10-2008

11

What We Really Need is Effective Separation of Concerns



Organization Green

Michelle

Dimitri

Program X


Organization Blue

Authentication

Authorization

• Build dynamic trust relationships

• Transport the security context so that authentication and authorization can be distributed

• Enforce privacy issues

• Time out sessions/global logout

Core Requirements

Trust

The Mechanism: Global Trust of Local Tokens



Michelle

Dimitri

Program X

Green’s Identity Server

Trust

1. Acquire trusted token with statement of authentication (and

possibly authorization, entitlements, attributes) in this

security domain

2. Validate token here according to

trust model

24-10-2008

12

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

Next Steps in SOA Security

Portable, canonical assertions:

SAML

Token distribution:

WS-Trust

Sessions:

WS-SecureConversation


24-10-2008

13

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.


24-10-2008

14

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


24-10-2008

15


…

Statement 1

Statement n

<SubjectConfirmation>

<KeyInfo>

<ds:Signature>

<ds:Signature>

<SOAP-ENV:BODY>

<SOAP-ENV:Header>

<SOAP-ENV:Envelope>

<SAML:Assertion>

Issuing Authority signature covers assertion and binds statements to Subject’s public key

Subject signs its message

The key used in Subject’s signature across the message body is the analogue of the one bound into the assertion.

Issuing Authority

Subject

The Mechanism: Global Trust of Local Tokens



Michelle

Dimitri

Program X

Green’s Identity Server

TrustSAML

SAML

1. Acquire trusted token with statement of authentication (and

possibly authorization, entitlements, attributes) in this

security domain

2. Validate token here according to

trust model

24-10-2008

16

WS-Trust: Typical Token Validation Request


<soapenv:Envelope><soapenv:Body>

<wst:RequestSecurityToken><wst:Base>

<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><wsp:AppliesTo>

<wsa:EndpointReference><wsa:Address>http://samlpart.com/sso</wsa:Address>

</wsa:EndpointReference></wsp:AppliesTo><wst:RequestType>...Validate</wst:RequestType>

</wst:RequestSecurityToken></soapenv:Body>

</soapenv:Envelope>

Incoming token

Issuer of Incoming token

Scope of intended use

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><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</wst:Code>

</wst:Status></wst:RequestSecurityTokenResponse>

</soapenv:Body></soapenv:Envelope>


Returned Token

WS-Security plumbing

24-10-2008

17

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?


24-10-2008

18

The Potential of Web Services – A Governance Nightmare?


getLevelInventory

update

order

Procurement

SOAP over http

XML encryption

Digital Signature

Guaranteed QoS

Non-repudiation audit logging

SOAP over http

XML encryption

Digital Signature

Guaranteed QoS

Non-repudiation audit logging

SOAP over https

LDAP based ACL

Text logging

SOAP over http

AD based ACL

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


24-10-2008

19

A Simple Analogy: Audio Systems

Monolithic, proprietary design

Fixed architecture and capabilities

Vulnerable to technology change

Single-source vendor

Expensive

RCA Jack: standard interfaces and data format; component design

Flexible architecture Future-proof Vendor-neutral Competition drives

prices down


One Step Further: Professional Sound Systems

Abstract out input devices and output devices.

Syndicate a variety of inputs to a variety of outputs.

Complete control over input and output parameters.

Abstract out requester origination points and provider endpoints.

Syndicate a variety of services to a variety of consumers.

Complete control over provider and consumer policies.


24-10-2008

20

From Business Drivers To Web Services: Reusable Components Framework


Business Drivers (Inputs)

-Revenue/Profit

-Market share

-Agility

Business Service Types

-Inventory

-CRM

-HR

-Accounting

-…

Business Services

-Get Inventory Levels

-Inventory Updates

-Forecasting

Business Services

-Get Customer Account

-Inventory Updates

-Forecasting

Web Services

-getInventoryBySKU

-getInventoryByPC

Reusable Business Components Framework

Web Services

-removeSKUItems

-addSKUItems

Business Services… Web Services …

Registry (MetaData)

Corporate And Architecture Drivers: Runtime Policy Framework


Corporate Policy Drivers (Inputs)

-Governance

-Compliance

-Security

Security

-WS-Security

-X509TokenProfile

-SAMLTokenProfile

-XML Encryption

-XML Signatures

Runtime Policy Framework

Corporate Architectural Drivers (Inputs)

-Flexibility and Reuse

-Platform Independence

-Integration with existing infrastructure

-Security, Scalability, Availability, Performance

Registry (MetaData)

Transport

-HTTP

-TLS

-JMS

SLA

-Response Time

-Availability

-IP Range, ToD

-Throughput Limits

-Non-repudiation

Message X-Form

-Versioning

-Localization

-DS (ACORD, FIX)

Reliability

-WS-RM

Threat Protection

-Schema Validation

-Virus Scanning

-Attachments

Platform

-Load Balancing

-WS-Addressing

24-10-2008

21

Joining The Two Frameworks:Policy Driven SOA


Reu

sab

le B

usin

ess C

om

po

nen

ts F

ram

ew

ork

Reu

sab

le B

usin

ess C

om

po

nen

ts F

ram

ew

ork

Ru

nti

me P

olicy F

ram

ew

ork

Ru

nti

me P

olicy F

ram

ew

ork

Man

ag

ed

Co

mm

un

icati

on

s I

nfr

astr

uctu

re

Decoupling Policy in Practice:The Policy Enforcement Point


Web Services Provider

Web Services Consumer Policy

Registry

Policy Document

WSDL Document

Policy Enforcement Point

24-10-2008

22

Decoupling Policy in Practice:The Policy Application Point


Web Services Provider

Web Services Consumer Policy

Registry

Policy Document

WSDL Document

Policy Enforcement Point

Policy Application

Point

Signed Policy

Document

Policy Conforming

SOAP Request

PEPs in the Architecture


External

Service

External

Service

External

Service

External

Service

DMZ

Centralized

PEP

Firewalls

(Perimeter PEPs)

Endpoint

PEP

Endpoint

PEP

Endpoint

PEP

Endpoint

PEP

Endpoint

PEP

Endpoint

PEP

Intermediary

PEP

Service Service Service

Service Service Service

Intermediary

PEP

Courtesy: Anne Thomas Manes, Burton Group

24-10-2008

23


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>

24-10-2008

24

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













http://www.sys-con.com/xml/article.cfm?id=772



24-10-2008

25

Thanks!

Thank you very much for making it through!

Email questions or comments or presentation requests to:

[email protected]


The Future of SOA Security

Documents

Transcript of The Future of SOA Security