1 / 24

Using PHINMS and Web-Services for Interoperability

Using PHINMS and Web-Services for Interoperability. Raja Kailar, Ph.D. CTO, Business Networks International Inc. Tim Morris – PHINMS Project Sponsor CDC/NCPHI Director, DISS. Overview. PHINMS Web Services extension phases Interoperability considerations Scalable Messaging Architectures

garnet
Télécharger la présentation

Using PHINMS and Web-Services for Interoperability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using PHINMS and Web-Services for Interoperability Raja Kailar, Ph.D. CTO, Business Networks International Inc. Tim Morris – PHINMS Project Sponsor CDC/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 3

  4. PHINMS 3.0 - Web-Services Reliable Messaging 4

  5. Current Message Transport Modes Direct-Send Route-not-Read

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

  8. Transport Architectures Under Consideration • Option 1: • Identity provider based Centralized/Federated authentication • Option 2: • Regional gateways with routing capability

  9. 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 10

  11. 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 12

  13. 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?

  14. 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 15

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

  17. Interoperation with Non-PHIN Networks

  18. Approach 1: Multiple Protocol Support 18

  19. 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 20

  21. Example – Non-PHIN to PHIN Message Flow 21

  22. Inter-Network Gateway Architecture 22

  23. 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 24

More Related