authentication proxy for the vista hospital information system william majurski information...
TRANSCRIPT
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.