1 / 22

Authentication Proxy for the V ist A Hospital Information System

Authentication Proxy for the V ist A Hospital Information System. William Majurski Information Technology Laboratory. Department of Veterans Affairs Hospital System. Serves medical needs of veterans 170+ medical centers 400+ outpatient locations Organized by region. V ist A.

tuyen
Download Presentation

Authentication Proxy for the V ist A Hospital Information System

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. Authentication Proxy for the VistA Hospital Information System William Majurski Information Technology Laboratory

  2. Department of Veterans Affairs Hospital System • Serves medical needs of veterans • 170+ medical centers • 400+ outpatient locations • Organized by region

  3. VistA • Veterans Health Information Systems and Technology Architecture • DHCP (Decentralized Hospital Computer Program) • Server written in M (MUMPS) • Timesharing • Client/Server • Administration - site/region

  4. Installed NT Network • Currently supports administrative functions • Uses NT Domain Model • Domain Controller • Centralized administration

  5. Basic Client/Server Client WS M Server • Native ORB

  6. Problem Statement • User population more mobile • Providers & patients dealing with more than one site • VistA network of computing services becoming more tightly integrated. • Current authentication scheme (userid/password) poses problems.

  7. Problem Statement (cont.) • Each user must have account on each system associated with his patients. • Must remember account names & passwords. • Repeated authentication is time consuming and distracting.

  8. Approach • Authentication Proxy • Network service that bridges security environments of • Underlying network environment (NT) • Hospital information system • Solves • Multiple account • Repeated Authentication problems.

  9. Approach Specifics • Authentication Proxy that translates NT authentication into VistA authentication • Map NT user identity -> VistA user identity • Automatically creating map • Event log

  10. NT Authentication • NT Domain • Collection of workstations and servers • Identified by domain name • managed from single administrator’s account • User login • To domain • Servers trust domain controller • Servers can identify user account

  11. Critical Technology • Security Support Provider Interface (SSPI) • API to integrated security services • Accessibility: • direct calls to API • RPC • Distributed Common Object Model (DCOM)

  12. Authentication Proxy • Runs on server running NT • Talk SSPI to client via DCOM • Tightly coupled with M Server

  13. Architecture Authentication Proxy DCOM Client WS NT NT NT (maybe) M Server

  14. Userid/Password Client WS NT (maybe) Setup => <= Challenge M Server Userid/password => <= Valid

  15. Authenticate with Proxy Authentication Proxy 1. Auth[user] => DCOM Client WS 3. <= Token 2. Auth(NT user, Token) 4. Token => M Server Token, NT user, expiration NT User -> M User

  16. User Map Initialization • NT identity from Authentication Proxy • M Server identity from login/password

  17. Proxy Initialization • M Server administrator must trust proxy • On M Server • Special account with password • Security key (controls access to map object) • On proxy • Install account/password

  18. Multiple M Servers • Authentication Proxy can handle multiple M Servers • M Server can trust multiple Authentication Proxies

  19. Event Logging • Each authentication attempt is logged • Information: • NT user • M user • Application context (application object) • Patient

  20. Object Technology + • All the detail protocol handling • Provided by vendors • Managed by objects. • Very small amount of code to be maintained • 200 lines M Server • 300 lines Proxy. • Value of objects - packaging for reuse.

  21. Object Technology - • Must understand many aspects of object • methods, initialization, interactions • New uses for old objects • Documentation from “wrong angle” • Comes with much integration (context) • Good as long as it is the right integration. • Reuse battle has just begun

  22. Thank You.

More Related