Authentication Proxy for the V ist A Hospital Information System

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.