1. Authentication Proxy for the VistA Hospital Information System William Majurski Information Technology Laboratory

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

3. RDOH’98 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. RDOH’98 Installed NT Network Currently supports administrative functions Uses NT Domain Model –Domain Controller –Centralized administration

5. RDOH’98 Basic Client/Server Client WS M Server Native ORB

6. RDOH’98 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. RDOH’98 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. RDOH’98 Approach Authentication Proxy –Network service that bridges security environments of Underlying network environment (NT) Hospital information system Solves –Multiple account –Repeated Authentication problems.

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

10. RDOH’98 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. RDOH’98 Critical Technology Security Support Provider Interface (SSPI) API to integrated security services Accessibility: –direct calls to API –RPC –Distributed Common Object Model (DCOM)

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

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

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

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

16. RDOH’98 User Map Initialization NT identity from Authentication Proxy M Server identity from login/password

17. RDOH’98 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. RDOH’98 Multiple M Servers Authentication Proxy can handle multiple M Servers M Server can trust multiple Authentication Proxies

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

20. RDOH’98 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. RDOH’98 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. RDOH’98 Thank You.