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

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

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

RDOH’98 Installed NT Network Currently supports administrative functions Uses NT Domain Model –Domain Controller –Centralized administration

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

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.

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.

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.

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

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

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)

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

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

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

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

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

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

RDOH’98 Multiple M Servers Authentication Proxy can handle multiple M Servers M Server can trust multiple Authentication Proxies

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

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.

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

RDOH’98 Thank You.