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

ClientWS

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

ClientWS

AuthenticationProxy

M Server

DCOM

NTNT (maybe)

NT

RDOH’98

Userid/Password

ClientWS

M Server

NT (maybe)

Setup =><= Challenge

Userid/password =><= Valid

RDOH’98

Authenticate with Proxy

ClientWS

AuthenticationProxy

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.