Using PHINMS and Web-Services for Interoperability

The findings and conclusions in this presentation are those of the author and do not necessarily represent the views of the Centers for Disease Control and Prevention/the Agency for Toxic Substances and Disease Registry.

Raja Kailar, Ph.D. CTO, Business Networks International

Inc.

Tim Morris – PHINMS Project SponsorCDC/NCPHI Director, DISS

2

Overview

• PHINMS Web Services extension phases

• Interoperability considerations– Scalable Messaging Architectures– Non-PHIN Networks

3

PHINMS 2.8 - Web-Services Adapter

PHINMS Sender

PHINMSReceiver

Web ServiceAdapter

Phase I: Web-Services Adapters

Web-ServiceClient

(receiver)

Web ServiceClient Web

ServiceAdapter

TQWQ

Web ServiceClient

(receiver)

Responses, RNR Data

Requests

PollPoll

4

PHINMS 3.0 - Web-Services Reliable Messaging

ebMS

WS-RM

ebMS

WS-RM

Phase II: Core Transport Extensions for WS-Reliable Messaging

ebMS

WS-RM

Web ServiceAdapter

TQ WQ

Web ServiceAdapter

SENDER

RECEIVER

Current Message Transport Modes

Route-not-Read Direct-Send

Maintainability/Scalability: Current Challenges

• Route-not-Read has single point of failure, performance bottleneck

• Direct-Send difficult to install (Firewall, DMZ etc)

• Lifecycle management of client certificates used for Sender authentication by Receiver’s proxy web-server

7

Transport - Long Term Goals

• Scalability– Support for thousands of messaging nodes

• Maintainability– Adding new nodes, or renewing certificates

at a node should not require manual updates at all other nodes

Transport Architectures Under Consideration

• Option 1: – Identity provider based Centralized/Federated

authentication

• Option 2: – Regional gateways with routing capability

Option 1: Identity Provider based Centralized/Federated Authentication

10

What is an Identity Provider?

• User identity proofing– e.g., Is this John Doe living at 123 Main St, TN?

• Identity binding to digital credentials– e.g., John Doe = Certificate with Serial No. 12312

• Periodic renewal of credentials, re-binding of identities

• Online authentication Service– e.g., Client-Certificates, Login and Password

• Standard based authentication and/or authorization (session) tokens– e.g., SAML assertions

What is SAML?

• Security Assertion Markup Language• Open standard for communicating

information:– Authentication– Authorization– Attribute

• Platform and Language independent (XML based)

• Can be used to support single sign-on and identity federation

12

Identity Provider and SAML Based Authentication Approach

RequestingParty

(Initiator)

Relying Party

(Responder)

Identity Provider

(SAML Authentication

And/or Authorization Authority)

1) ID + Authentication

Credentials 2) Assertion(s)

3) SOAP Request+

Assertions

0) TrustRelationship

Identity Providers – Advantages and Challenges

Advantages• Centralized control over authentication and/or

authorization• User identity management burden shifted from

services that use identity

Challenges• Establishing trusted identity providers

– More than technology– Service requestor and responder need to agree on

same authentication/authorization mechanisms• Centralizing trust can create single point of failure,

target for hack attacks• Standards (e.g., SAML, WSS) are evolving• Where is authorization performed?

Option 2: Regional Gateways with Routing Capability

15

Regional Gateways

Messaging/routing– Nodes authenticate

to gateway

– Send/Poll model at each regional gateway

– Gateways perform message routing

Regional Gateways – Advantages and Challenges

Advantages– No single point of failure– Local control of identities and processes– De-couples intra-regional interfaces from inter-regional ones

Challenges– Authentication/authorization not necessarily end-to-end

• Gateways may act as trusted intermediaries (transitive trust)

• Need policies, binding agreements between regional gateways

– End-to-End routing, encryption– Acknowledgements in multi-hop mode

Interoperation with Non-PHIN Networks

18

Approach 1: Multiple Protocol Support

Iowa

PHIN Non-PHIN

SanDiego

CDCebMS +2-way SSL

Transport + SecurityProtocol 2

CDC

Multiple Protocol Support: Challenges

• Addition of each new protocol requires upgrade of messaging node software

• Complexity of messaging nodes go up (multiple security credentials, protocols etc)

20

Approach 2: Inter-Network Gateways

Iowa

PHIN Non-PHIN

IdentityProvider

SanDiego

Inter-NetworkGateway

CDC

CDC Gateway,On Behalf of Iowa,Message Type X

Authenticate

Service=GatewayAction=send

MessageRecipient= San Diego @Other Network

Arguments=Message Type X

Poll

Hub

21

Example – Non-PHIN to PHIN Message Flow

Iowa

PHIN Non-PHIN

IdentityProvider

SanDiego

Inter-NetworkGateway

CDC

Send to Iowa,Message Type X

Authenticate

From-PartyId=CDC GatewayService=NonPHINMessages

Action=sendArguments=Message Type X from San

Diego

22

Inter-Network Gateway Architecture

PROTOCOLTRANSLATOR

INTER-NETWORKSECUREROUTER

PHIN(ebMS 2.0)

Non-PHIN(e.g., Web-Services)

Non-PHIN(e.g, Web-Services)

PHIN(ebMS 2.0)

Inter-Network Gateways – Advantages and Challenges

Advantages– Facilitates re-use of existing messaging systems to

support new data routes and business use cases

Challenges– Agreements (policy, business, service-level)

between different networks on gateway protocols, routing, security

– Trust on gateways• End-to-end messaging security properties

– Authentication– Confidentiality

24

Summary

• Current models are secure but may not scale to large number of nodes

• New models are scalable/maintainable, but there are security challenges:• Centralizing authentication / authorization• Regional gateways (transitive trust)

• Security - Technology is a small part of the problem. Bigger challenges are:• Establishing trust in identity proofing,

authentication and authorization• Policy, Governance, Agreements on inter-

organizational or inter-regional entities