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




XML Based
Protocol Independent
Standards based
Extendable


Robust





Supports an extension model
similar to MISMO today.
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.
SOAP is not

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 machineprocessable 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 Webrelated 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
Extensions
Emerging Core
Core Standards
WS-BPEL
WS-MetaDataExchange
WS-Transaction
WS-Coordination
WS-Events
WS-Policy
WS-Security
WS-Reliable
Messaging
WS-Addressing
UDDI
WSDL
SOAP HTTP SSL
Discovery
Description
Delivery
Can MISMO use SOAP without
Web Services?

Yes


A complete Web Service-based solution is out of scope



SOAP is an independent specification
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



Routing


Flexibility to identify multiple intermediaries via pass through
headers
Messaging




XML encryption
Authentication (Digital signatures)
Unique message identification
Large attachments/Messages
Preferred Response(s)
Compression
Mapping MISMO to SOAP and
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




Phase 2: Possible in the near future






WS-Addressing
WS-Security MISMO Security Workgroup
WS-Reliable Messaging
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
SOAP Header
WS-Security
WS-Addressing
Security Header Block
Addressing Header Block
XML
SOAP Body
MISMO
XML Payload
Sample WS-Addressing SOAP
Header with MISMO Payload
Headers
Body
Current WS* Overview
Extensions
Emerging Core
Core Standards
WS-BPEL
WS-MetaDataExchange
WS-Transaction
WS-Coordination
WS-Events
WS-Policy
WS-Security
WS-Reliable
Messaging
WS-Addressing
UDDI
WSDL
SOAP HTTP SSL
Discovery
Description
Delivery
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
Provider Boundary
Service
Requestor
Service Provider
Xml
MISMO
Scenario 1
SOAP Client, SOAP Intermediary,
and SOAP Ultimate Receiver
Client Boundary
Service
Requestor
(SOAP Node)
SOAP Intermediary
Service Provider
Service Provider
(SOAP Node)
SOAP Sender
(SOAP Node)
Xml
SOAP/MISMO
Message contains information
for the original request and
information intended to be
passed through the intermediary
and destine for the end SOAP
node.
Scenario 2
Xml
SOAP/MISMO
Certain XML headers in the
SOAP header are passed
through the intermediary to
the SOAP server based on
their defined role.
SOAP Client, Intermediary, Server
MISMO Use Case
Client Boundary
Service
Requestor
LOS
Xml
SOAP/MISMO
SOAP Intermediary
Service Provider
Service Provider
SOAP Sender
Portal
Xml
SOAP/MISMO
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




Message Signing / Integrity


Username/Password (Clear/HASH Security token)
PKI through X.509 Certificates (Security token)
Kerberos (Security token)
All, part or external message (XML Signature)
Message Encryption

All, part or external message (XML Encryption)
WS-Sec – Authentication
Compatible
support for
UserId/Passwd
exchange
Username to be
authenticated
Password to
be used
Problem: Password is still in
clear text and therefore
problematic for the intermediary
situation.
WS-Sec – Authentication/Hash
Password now sent
as a SHA1 digest
instead of clear text
Advantages:
1. No clear text
2. Anti-reply attack
3. 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 WSURL this
Addressing
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


Concentrate
on these
aspects of
RM


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 nondecreasing. It says nothing about duplications or omissions.
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
Enveloping
SOAP POC
Milestone
1/25/2006
2/1/2006
Mismo Milestones
3/1/2006
4/1/2006
5/1/2006
6/1/2006
7/5/2006
Determine SOAP based envelope
Structure (Header vs Body)
7/25/2006
Review if what is in the envelope
Makes sense and if it should stay or be moved
9/5/2006
Review structure POC
With Enveloping Group
10/15/2006
Begin POC coding
With Java and .NET clients
11/14/2006
Complete SOAP based
POC
7/1/2006
8/1/2006
9/1/2006
10/1/2006
11/1/2006
12/1/2006
1/1/2007
1/25/2007
9/12/2006
Mismo 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.