This paper describes the concept and design of an Authentication Proxy, a network service that bridges the security environments (specifically authentication) of an underlying network environment (Windows NT) and the VistA hospital information system. The current Authentication Proxy offers a solution to the problem of users remembering account names and passwords for multiple frequently used systems and the repeated authentication necessary when moving between these systems.
VistA is a hospital information system developed within the Department of Veterans Affairs to support clinical and administrative functions in VA Medical Centers. VistA (formerly known as DHCP) is based on the M (MUMPS) language. M offers an integrated language, database environment, and operating environment which can be hosted on top of many native operating systems such as Unix and Windows NT. The core of the hospital system is the M Server. This M Server operates as both a timesharing resource for older terminal based applications and as a network server for newer client/server applications.
The RPC Broker is a client/server system within VistA environment. It enables client applications to communicate and exchange data with M Servers. Client access to broker is packaged as a Windows DLL and as a module for Borland Delphi applications. Applications constructed with these tools can easily access application objects running in M within the VistA environment. An application object, or application context, on the server provides methods for manipulation by the client. Broker is fully integrated into the existing security infrastructure including authentication and access control. Authentication takes the form of a login/password dialog to authenticate the user to the M server.
In a separate development, the VA has been deploying NT servers and using NT network security to manage office automation. The NT network security uses the NT Domain Model. This domain model allows a certain amount of centralization in the management of network account information[1]. The VA has applied this technology to the design of a nationwide NT network.
This paper describes the concept and design of an Authentication Proxy, a network service that bridges the security environments (specifically authentication) of an underlying network environment (Windows NT) and the VistA hospital information system. The current Authentication Proxy offers a solution to the second and third problem above. Later phases of this project will address the first problem.
Specifically, this project has:An NT Domain is a collection of workstations and servers. This collection is identified by a domain name and is managed from a single distributed administrator’s account. The common point for management is a server identified as a domain controller. A user login to an NT workstation that is part of an NT Domain authenticates to the domain controller by providing a user name, password, and a domain selection. When the user attempts to use a network service offered by a server within the domain, that server can accept the now established user identity maintained by the NT security infrastructure. The server need only trust the domain controller. Responsibility has shifted from trusting a user workstation and logon to trusting the domain and the domain administrator. During logon, the domain server hands off to a trusted part of the user’s NT workstation, a security kernel, and the user’s verified identity. This identity can be passed on to any requesting server or service.
The key piece of technology in this prototype is the Security Support Provider Interface (SSPI)[2] available on Windows NT. SSPI is an API for access to integrated security services for authentication, message integrity, message privacy, and security quality of service for any distributed application protocol. Access to this interface is provided in three ways: direct access to the API, integration with the native RPC facilities and through an object model – the Distribute Common Object Model (DCOM). DCOM offers a distributed execution model for distributed computing. When integrated with software services it is referred to as OLE Automation. OLE Automation is one of the object types available within Delphi.
A service implemented with OLE Automation can retrieve the authenticated identity of the user account that called the OLE Automation client through trusted operating system mechanisms. We leverage this authentication information to create a network authentication service for VistA.
The Authentication Proxy (AP) runs on NT to ensure access to the SSPI interface and therefore have native access to user authentication information. Administrative coupling between the AP and the M Server is important since the administrator responsible for the M Server must trust the installation and operation of the AP. The broker provides communication between the AP and the M Server.
In the current VistA environment, brokered client applications initialize by connecting to the M Server. Library code installed as part of the client presents the system sign-on dialog window to the user. The login/password codes that are entered by the user are sent to the M Server. If valid, the session is established and the application is initialized.
Authentication using the Authentication Proxy is started by the client application making a call (via DCOM) to the Authentication Proxy (AP). The AP extracts from the underlying security context the domain name and the user name of the caller (user of the NT workstation). The AP then creates a one-time key or token, a long random string that is used only once. The token is sent to the M Server along with the identity of the user. The M Server saves the token, the user identity and a server imposed expiration time. Back in the Authentication Proxy, the DCOM call returns to the client with the token. Both the server and client now have a copy of the authentication token. The client process now sends the authentication token to the M Server as part of the request for connection. When the M Server receives the token from the client it finds the copy of the token it has stored (that it received from the Authentication Proxy). It checks the expiration time of the token for tardiness. No access is given to tardy connections. If no problems occur then the authentication is accepted. Several attributes of the authentication processing are logged for accountability.
The mapping from NT user identifiers and domain names to M Server users must be created. While it is possible to create this mapping manually, it can also be created incrementally as the system is used.
Authentication starts with the user signing on to the workstation. NT challenges the user to provide a user name, password and the local domain name. Launching a brokered application that uses the Authentication Proxy starts by communicating with the AP. The resulting AP – M Server communication determines that there is no mapping between this NT user and an M Server user. As a result, the user is challenged to provide a valid user name and password for the M Server. If successful, the mapping from NT user to M Server user is remembered. Once the mapping is created, the NT authentication alone is trusted.
The Authentication Proxy (AP) must be initialized in a way that the M Server (and its managers) can trust the integrity of the AP. Because of the diversity of platforms that can support the M Server, the AP may run on the same machine or on a separate machine. This section details a procedure for establishing an AP in a manner that the M Server can trust.
Before an AP can pass on authentication information to the M Server it must establish a connection to the M Server. This connection, like all others is protected by login/password.
A special VistA account is created for the AP to use. We will call this special account the Authentication Proxy Account or AP Account. Account name and password are created for this account.
A new security key is created within the M Server. The AP Account is the only holder of this new key. Performing the duties of interfacing to the AP require this key (permission to store an authentication token or update the NT user to M Server user map).
When the AP is installed on an NT server, the installer must provide the access and verify codes for the Authentication Proxy Account. These codes are encrypted and saved on the NT server. When the AP connects to the M Server, it needs to authenticate itself, these codes are passed (encrypted) to the M Server via a broker call.
The Authentication Proxy account name and passwords are stored on the NT server and are protected by:A single AP can front-end multiple M Servers. The request to the AP from a client includes the name of the M Server of interest. The AP must be trusted by the operators of each of the M Servers.
Moving from a local to a distributed authentication scheme establishes that possibility for additional risks. To help manage those risks, a system of event logging has been introduced. Each authentication attempt is logged. The log information includes NT user identity, M Server identity, patient selected, Authentication Proxy used, time, and the application context (object connected to).
A technique has been presented for replacing the use of login name and password style authentication with a bridge to a distributed authentication mechanism. A mapping between network accounts and local accounts is created and maintained. This mechanism is adaptive in the sense that new users are challenged to enter account names and passwords by both the distributed operating system and the local hospital information system that is being protected. Once successfully challenged, the user account is stored in a map. Subsequent access to the hospital system is governed only by the distributed system authentication.
The use of object technology greatly simplified the construction of this prototype. If the prototype moves to production, maintenance effort will be greatly reduced. This results from the amount of code necessary to implement the new functionality. Without the object encapsulation, access to the security environment and protocols would be via direct RPC or low level calls to the security API. The result is a large amount of application code to maintain. The reusability gained by object encapsulation makes the use of the new technology cost effective.
This paper represents a prototype created by NIST for the Department of Veterans Affairs. Because of the nature of this report, it is necessary to mention vendors and commercial products. The presence or absence of a particular trade name product does not imply criticism or endorsement by the National Institute of Standards and Technology, nor does it imply that the products identified are necessarily the best available.
[1] Karanjit S. Siyan, "Windows NT Server 4 – Professional Reference", New Riders, 1996.
[2] http://premium.microsoft.com/msdn/library/conf/html/s9eae.htm
This paper represents a prototype created by NIST for the Department of Veterans Affairs. Because of the nature of this report, it is necessary to mention vendors and commercial products. The presence or absence of a particular trade name product does not imply criticism or endorsement by the National Institute of Standards and Technology, nor does it imply that the products identified are necessarily the best available.