SOAP based WS* Standards and MISMO

SOAP based WS* Standards and MISMO

Agenda Review standards & technologies

relating to SOAP, XML, Web Services, and the WS* standards

Roadmap for moving MISMO towards a SOAP based solution

Industry’s challenges, advantages, disadvantages of moving to a SOAP based communications framework

What is SOAP? A standardized message structure

based on the XML Infoset A processing model that describes how

a service should process the messages A mechanism to bind SOAP messages to

different network transport protocols A way to attach non-XML encoded

information to SOAP messages Current version 1.2

What is SOAP? 3 aspects of SOAP Message

Envelope Header Body

SOAP is SOAP is not XML Based Protocol Independent Standards based Extendable

Supports an extension model similar to MISMO today.

Robust High adoption rate Cross industry buy in Seasoned Standard since

(2000) Strong 3rd party support

Independent of Web Services Web services have an

implementation as SOAP based extensions.

Protocol Dependant SOAP over MQ HTTP

What are Web Services? W3C Definition

A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.

What are the WS* Specifications/Standards? A set of requirements that codify

typical problem areas trading partners face when communicating over the internet.

XML based specifications and standards

SOAP based extensions

WS* SOAP Based Standards/Extensions Stack

SOAP HTTP SSL

WS-Security

Discovery

UDDI

Description

WS-Policy

WSDL

WS-BPEL

WS-MetaDataExchange

Delivery

WS-Reliable Messaging WS-Addressing

WS-Transaction WS-Coordination

Core Standards

Emerging Core

Extensions

WS-Events

Can MISMO use SOAP without Web Services? Yes

SOAP is an independent specification A complete Web Service-based solution is out of scope

Discovery Description

SOAP and Web Services are two independent adoptions There are SOAP extensions that have nothing to do with

Web Services SOAP allows MISMO to create their own extensions if we

desire Some WS Standards do not deal with the concepts of Web

Services Other WS Standards require the core concepts of Web

Services and are designed to support these services

Current MISMO challenges that SOAP can help solve. Security

XML encryption Authentication (Digital signatures)

Routing Flexibility to identify multiple intermediaries via pass

through headers Messaging

Unique message identification Large attachments/Messages Preferred Response(s)

Compression

Mapping MISMO to SOAPand WS* Can be implemented in several

different ways, all that are within the SOAP spec are “right”.

Standards/Specifications allow us to leverage multi-industry experts experience and knowledge.

What else can SOAP provide MISMO? Allow MISMO to concentrate on the

business of real estate transactions properties, borrowers, products .

Increased adoption/speed of integration by using open standards, tools, and 3rd party products.

Flexibility to allow MISMO workgroups to continue to push forward on pressing issues

Roadmap to SOAP, WS* Evolution not revolution Decide what can be placed in SOAP

headers and what can stay in body Decide whether to use current standards

or leverage SOAP extensibility (e.g. with an oversight body & approval)

Complete proof of concept Begin with basic SOAP headers

WS-Addressing WS-Security WS-Reliable Messaging

Which WS* Standards make sense for MISMO? Phase 1: Direct mappings to MISMO Envelope today

WS-Addressing WS-Security MISMO Security Workgroup WS-Reliable Messaging

Phase 2: Possible in the near future WS-Coordination- Multi-Services Workgroup WS-Eventing WS-Transaction WS-Coordination- Multi-Services Workgroup WS-BEPL- BREW

Phase 3: Potential Long Term Options WS-Metadata Exchange WS-Policy

Conceptual Sample SOAP based Envelope MISMO structure

SOAP Envelope

Security Header Block

Addressing Header Block

SOAP Body

SOAP Header

XML Payload

XML

WS-Security

WS-Addressing

MISMO

Sample WS-Addressing SOAP Header with MISMO Payload

Headers

Body

Current WS* Overview

SOAP HTTP SSL

WS-Security

Discovery

UDDI

Description

WS-Policy

WSDL

WS-BPEL

WS-MetaDataExchange

Delivery

WS-Reliable Messaging WS-Addressing

WS-Transaction WS-Coordination

Core Standards

Emerging Core

Extensions

WS-Events

For initial MISMO enveloping strategy concentrate on SOAP and message related standards first then evaluate other soap based standards as the need arises

How can SOAP and MISMO be Used Together Headers are used for

protocol/messaging specific items. (Headers are optional)

MISMO may be passed in the body of the SOAP message with little or no change to structure

MISMO XML Body goes here

What functionality do the MISMO headers provide today? Trading Partner information via

MISMO XML Submitting Party

Preferred Response Requesting Party Receiving Party

SOAP Node (Party), Roles, and Targeted Headers SOAP embraces the concepts of multiple

Nodes communicating together. SOAP defines 3 roles which can be put in

the header(s) to target the SOAP headers to specific Nodes along the service chain. (Insert roles here)

SOAP can be extended to support more roles as the need arises.

Client Server Integration

Client Boundary

Service Requestor

Provider Boundary

Service Provider

XmlMISMO

Scenario 1

SOAP Client, SOAP Intermediary, and SOAP Ultimate Receiver

Client Boundary

Service Requestor

(SOAP Node)

SOAP Intermediary

Service Provider(SOAP Node)

Service Provider

SOAP Sender(SOAP Node)

XmlSOAP/MISMO

XmlSOAP/MISMO

Message contains information for the original request and information intended to be

passed through the intermediary and destine for the end SOAP

node.

Certain XML headers in the SOAP header are passed through the intermediary to the SOAP server based on their defined role.

Scenario 2

SOAP Client, Intermediary, ServerMISMO Use Case

Client Boundary

Service Requestor

SOAP Intermediary

Service Provider

Service Provider

SOAP Sender

XmlSOAP/MISMOLOS Portal Product

Company

Securing SOAP•SOAP is the Foundation

•WS-Security is the Baseline

MISMO Security Requirements Requirements

Multiple security tokens for authentication or authorization

Multiple encryption technologies Payload integrity Multiple trust domains End-to-end message-level security

Security Issues w/ existing MISMO Envelope specification Clear text password is a security risk Clear text passwords transmitted

through intermediaries exposes all parties to unauthorized access

No embedded confidentiality of payload

No embedded integrity of payload Authentication multiple end point

support

WS-Security (SOAP Message) Design Goals

“… flexible set of mechanisms that can be used to construct a range of security protocols; in other words this specification intentionally does not describe explicit fixed security protocols.”

WS-Security Support Authentication

Username/Password (Clear/HASH Security token) PKI through X.509 Certificates (Security token) Kerberos (Security token)

Message Signing / Integrity All, part or external message (XML Signature)

Message Encryption All, part or external message (XML Encryption)

WS-Sec – Authentication

Username to be authenticated

Password to be used

Problem: Password is still in clear text and therefore

problematic for the intermediary situation.

Compatible support for

UserId/Passwd exchange

WS-Sec – Authentication/Hash

Password now sent as a SHA1

digest instead of clear text

Advantages:1. No clear text2. Anti-reply attack3. Intermediate

confidentiality

WS-Security Auth Summary When done correctly, a digest will

prevent replay attacks Digest provides confidentiality WS-Security also supports field level

encryption of the username and password, but only secure when done correctly. (Encryption vulnerable to replay/offline dictionary attack.)

WS-Addressing Design Goals

…provide a transport-neutral mechanisms to address Web services and messages. Provide a specification that enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.

WS-Addressing Requirements

Ability to provide service endpoint reference information within SOAP headers

Ability to uniquely identify message that is sent to endpoint

Ability to define attributes for the return endpoint location.

Sample MISMO XML utilizing WS-Addressing URL this

message is being sent to

URL this message is being

sent from

URL the response should be sent back

to

Sample WS-Addressing SOAP Header with MISMO Payload

Maps to MISMO Preferred Response

WS-Reliable Messaging Defined Design Goals

Provide a SOAP based mechanism to for two services that wish to communicate to do so reliably in the presence of software component, system, or network failures. The primary goal of this specification is to create a modular mechanism for reliable message delivery. It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination. [spec 2004 Introduction]

WS-Reliable Messaging Supports Four messaging delivery assurances models

AtMostOnce-Message will be delivered at most once or an error will be raised

AtLeastOnce-Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.

ExactlyOnce-Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.

InOrder -Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions.

Concentrate on these aspects of RM

WS-Reliable Messaging Requirements

Support Works well with other SOAP based

standards that solve MISMO Issues. WS-Security WS-Addressing

WS-Reliable Messaging Benefits for MISMO Advantages

eMortgage Guaranteed delivery Acknowledgement of message receipt

and order of message receipt Others

WS-Reliable Messaging Sample

WS-Addressing Header

WS-Reliable Messaging Header

1/25/2006

1/25/2007

2/1/2006

3/1/2006

4/1/2006

5/1/2006

6/1/2006

7/1/2006

8/1/2006

9/1/2006

10/1/2006

11/1/2006

12/1/2006

1/1/2007

Mismo MilestonesEnveloping SOAP POC Milestone

10/15/2006Begin POC coding

With Java and .NET clients

11/14/2006Complete SOAP based

POC

9/5/2006Review structure POCWith Enveloping Group

7/25/2006Review if what is in the envelope

Makes sense and if it should stay or be moved

7/5/2006Determine SOAP based envelope

Structure (Header vs Body)

9/12/2006Mismo Face to Face

New Challenges SOAP brings “The XML looks harder to

understand” Expectations- It does not solve all

problems! (Provides framework to address the issues)

Competing / changing specifications and standards from various industry groups.