220 likes | 376 Views
Authentication Proxy for the V ist A Hospital Information System. William Majurski Information Technology Laboratory. Department of Veterans Affairs Hospital System. Serves medical needs of veterans 170+ medical centers 400+ outpatient locations Organized by region. V ist A.
E N D
Authentication Proxy for the VistA Hospital Information System William Majurski Information Technology Laboratory
Department of Veterans Affairs Hospital System • Serves medical needs of veterans • 170+ medical centers • 400+ outpatient locations • Organized by region
VistA • Veterans Health Information Systems and Technology Architecture • DHCP (Decentralized Hospital Computer Program) • Server written in M (MUMPS) • Timesharing • Client/Server • Administration - site/region
Installed NT Network • Currently supports administrative functions • Uses NT Domain Model • Domain Controller • Centralized administration
Basic Client/Server Client WS M Server • Native ORB
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.
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.
Approach • Authentication Proxy • Network service that bridges security environments of • Underlying network environment (NT) • Hospital information system • Solves • Multiple account • Repeated Authentication problems.
Approach Specifics • Authentication Proxy that translates NT authentication into VistA authentication • Map NT user identity -> VistA user identity • Automatically creating map • Event log
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
Critical Technology • Security Support Provider Interface (SSPI) • API to integrated security services • Accessibility: • direct calls to API • RPC • Distributed Common Object Model (DCOM)
Authentication Proxy • Runs on server running NT • Talk SSPI to client via DCOM • Tightly coupled with M Server
Architecture Authentication Proxy DCOM Client WS NT NT NT (maybe) M Server
Userid/Password Client WS NT (maybe) Setup => <= Challenge M Server Userid/password => <= Valid
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
User Map Initialization • NT identity from Authentication Proxy • M Server identity from login/password
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
Multiple M Servers • Authentication Proxy can handle multiple M Servers • M Server can trust multiple Authentication Proxies
Event Logging • Each authentication attempt is logged • Information: • NT user • M user • Application context (application object) • Patient
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.
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