Post on 14-Jan-2016
description
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