Method and System for Authenticating Access to Heterogeneous Computing Services

The present invention relates generally to a computer system for authenticating access to computing services and, more specifically, to a method and system for authenticating access to multiple heterogeneous resources while minimizing the number of user interactions.

In a networked computing environment, it is typical for multiple computer systems to be connected together through a physical communications link, which comprises the network. Typically, each computer system (node) that desires to use the services of another computer system (node) acts as a client node. A client node contains hardware for connecting to the network and a collection of software components for communicating with the hardware to access network services and for providing higher level network services. This collection of software components is collectively referred to as a network driver for convenience, even though the collection actually may comprise several drivers and other modules such as protocols and redirectors. Some network drivers provide a degree of security before they allow a program or user to access the services provided by the network. It is typical in these more secure environments for network drivers to require a user to "logon" to the network for the network driver to allow access to the network services it provides. The logon mechanism typically involves displaying some kind of user interface (e.g., a dialog window) and requires the user to enter identification information such as a user name and a password. The network driver then performs an authentication procedure for validating the entered identification information against known information to verify that the user is permitted to access the network services. The validation process may involve directly comparing the information or comparing by-products of the information using well-known encryption and decryption techniques. For example, the network driver may store passwords for each user that is allowed to access the network. During the authentication procedure, the network driver compares the entered password for that user name with the previously stored password information by using the entered password to encrypt a randomly agreed number. When a match occurs, the network driver permits access to the network services. Typically, a separate logon mechanism is required by each network driver and by the computer system (the local node) to gain access to the local computing services when a secure local environment is maintained.

The limitations of prior systems are overcome by the present invention, which is an improved method and system for authenticating access to heterogeneous computing services. In a preferred embodiment, a driver is designated as the primary logon provider, which provides an initial user interface for a sequence of logon interactions. When the computer system is powered up, and at other times when logon is desired, the primary logon provider is invoked and attempts to collect and authenticate identification information for access to the computing services it provides. When the driver serving as the primary logon provider successfully authenticates the collected identification information, the computer system attempts to authenticate the same identification information for access to system computing services without displaying additional user interfaces.

In one embodiment, the primary logon provider is a network driver, which provides access to network services. Once identification information has been collected and authenticated by this network driver, the local computer system has access to the network services provided by the network driver designated as the primary logon provider. The local computer system can then use the same identification information to authenticate access to local computing services.

In another embodiment, multiple logon providers are present in the computer system, each of which has its own authentication mechanism. In this embodiment, each logon provider other than the primary logon provider attempts to authenticate the identification information collected by the primary logon provider without displaying additional user interfaces for collecting additional identification data.

In yet another embodiment, the primary logon provider determines whether it is actively connected to the physical device or pseudo-device for which it provides services. When the primary logon provider determines that it is not actively connected, the primary logon provider avoids user interaction by not displaying its logon user interface. The authentication code of the computer operating system then displays its own user interface to collect identification information for authenticating access to system services.

In yet another embodiment, multiple logon providers are present in the computer system, each of which determines whether it is actively connected to the physical device or pseudo-device for which it provides services. When it determines that it is not actively connected, the provider avoids user interaction by not displaying its logon user interface.

In yet another embodiment, each logon provider is a network driver that is connected to a different (heterogeneous) network. Each network driver attempts to utilize the identification information collected by the primary logon provider to authenticate access to its own network without displaying another user interface.

In yet another embodiment, a user can control the logon user interface presented by a computer system by designating which logon provider is to serve as the primary logon provider.

In yet another embodiment, system authentication information is stored on a different network node other than the local computer system. The primary logon provider provides access to this system authentication information. Once a user has completed the logon mechanism to gain access to the network services provided by the primary logon provider, the local computer system has access to the system authentication information stored on the different network node. The local computer system logon mechanism uses this system authentication information to authenticate the collected identification information for access to local system services.

FIG. 1 is an example network configuration dialog for designating a primary logon driver.

FIG. 2 is an example screen display of the Windows operating system logon user interface.

FIG. 3 is an example screen display of a logon dialog of a network client driver serving as the primary logon provider.

FIG. 4 is a block diagram of a general purpose computer for practicing preferred embodiments of the present invention.

FIG. 5 is a block diagram of the software architecture of the present invention implemented in a network environment.

FIG. 6 is an overview flow diagram of the steps performed by the Multiple Provider Router code to authenticate identification information for access to the local computer system and to the current configured networks.

FIG. 7 is a detailed flow diagram of the logon sequence provided by a preferred embodiment of the MPR code.

FIG. 8 is a flow diagram of an example logon routine implemented by a logon provider.

Embodiments of the present invention provide methods and systems for authenticating access to heterogeneous computing services using a single user interface. According to the present invention, a user designates a driver to serve as a primary logon provider by means of a configuration dialog. For the purposes of this invention, a driver is any software code that provides a published or known set of routines for accessing a set of services. For example, a device driver that provides access to a disk drive (a device) is a driver, as is database code that provides access to a database (a pseudo-device). When the computer system is powered on, or at other system initialization times, the computer system invokes a logon mechanism to enable the user to gain access to different computing services, each of which require authentication of identification information to validate the user for authorized access to the services provided. Each driver that supports a logon mechanism and requires authentication for access to its services is referred to as a logon provider. According to the present invention, the logon mechanism invokes the designated primary logon provider to display a user interface for collecting identification information such as a user name, a password and an entity to validate against such as a domain name. Once the user enters the user's identification information, the primary logon provider authenticates this information using its own authentication procedure. Subsequently, the logon mechanism attempts to authenticate the already entered identification information for access to other computer system services without displaying additional user interfaces. Next, for each additional logon provider configured into the system, the computer system invokes that driver passing the identification information already collected. Each additional logon provider is then responsible for authenticating this same information for access to its services and attempts to do so without displaying an additional user interface. In this manner, the number of times a user is prompted to enter logon identification information is minimized.

Although the present invention is discussed below specifically with reference to network drivers, one skilled in the art will appreciate that the present invention is useful in other contexts as well, such as for other drivers that require logon authentication for access to their services. One example of such a driver is a database driver that provides secure access to its databases. Another example is an electronic mail server that provides secure access to a mail system (whether or not the computer is connected to a network). The mail system and databases are considered, "pseudo-devices" because they are being treated like physical devices, with access to them controlled by their drivers.

Embodiments of the present invention also provide a mechanism for displaying the user interface of the primary logon provider only when the driver is actively or successfully connected to the device (or pseudo-device) it services. The notion of an active or successful connection is driver defined. For example, in a networking environment where a portable computer may or may not be currently physically connected to a network, a logon user interface would only be displayed when the computer system is physically connected to the network. This mechanism prevents a user from being confronted with multiple user interfaces simply because the computer system is not currently connected to a device or because the connection has failed for some other reason. Otherwise, the user would be needlessly confronted with a user interface even when no access to the device is possible or when the access would fail or not make sense.

FIG. 1 is an example configuration dialog for designating a primary logon provider in a network environment. The network configuration dialog 100 contains a property sheet 101 for configuring various network components. The list box 102 shows the network components that are currently installed in the computer system. The add button 104 allows a user to add four types of network components, including the following components: client drivers (network software drivers) that enable the computer to connect to other computers via the network services supplied by the client driver (e.g., Banyan VINES, Netware, and Client for Microsoft Networks); adapters, which are software modules that correspond to various hardware devices that physically connect the computer to the network (e.g., IBM TokenRing, Microsoft DialupAdapter, or Racal ES3210 EISA); protocols, which are language modules the computer uses to communicate over the network (e.g., the Banyan VINES protocol, Microsoft NetBEUI, or Microsoft TCP/IP); and services, which are software modules that enable other computers on a network to share folders, printers, and other resources residing on this computer. Once the user has installed the desired network components, a list of configured network client drivers is provided in Primary Network Logon list box 103. The user selects a primary network provider by selecting one of the client drivers from this list box. As shown, the list box 103 contains two different client drivers: the Banyan VINES driver and the Client for Microsoft Networks driver. In addition, the list box 103 contains an entry for the Windows Logon code. The Windows Logon code refers to the authentication code provided by the Windows operating system for validating access to local computing services (e.g., access to the local "desktop"). The Windows Logon code entry allows a user to select the authentication code provided by the Windows operating system as the primary logon provider instead of a network driver. The driver selected as the primary network provider is the driver responsible for displaying an initial user interface to collect the user identification information, such as a user name, a password and a domain name. When the Windows Logon entry is selected from the list box 103 as the primary logon provider, the Windows operating system will supply its own user interface as the initial logon user interface.

FIG. 2 is an example screen display of the Windows operating system logon user interface. The dialog box shown in FIG. 2 is displayed when the user powers up the computer system, or at other times when logon is appropriate, and has previously selected the Windows Logon entry from the list box 103 (shown in FIG. 1) as the primary logon provider. Dialog box 201 contains two fields for entering identification information to the computer system. A user name field 202 is provided to enable a user to enter a user identification sequence, e.g., a set of letters, numbers and other characters. A password field 203 is provided to enable the user whose user name is displayed in the user name field 202 to enter an access code. This access code ensures secure access to the computer system. That is, unless the user enters the "correct" password in the password field 203, the user is denied access to certain capabilities within the Windows operating system.

Once the user enters identification information and presses the OK button 204, the Windows operating system authenticates the collected information. This authentication procedure involves checking whether the password entered in the password field 203 is a valid password for the user name entered in the user name field 202. If the password is valid for the specified user name, then the authentication is successful. One skilled in the art will recognize that there are many ways to store information regarding which passwords are valid for which user names. For example, a simple text file stored under an unpublicized name can be used. Alternatively, a secure file itself protected by a password can be used. Other implementations are possible.

If, instead of selecting the Windows Logon code as the primary logon provider, the user had selected a network client driver from the list box 103 in FIG. 1, then the logon user interface for that particular network driver is displayed when the user powers up the computer system or at subsequent times when logon is desired. FIG. 3 is an example screen display of a logon dialog of a network client driver serving as the primary logon provider. Dialog box 301 is a driver-specific dialog provided by the Client for Microsoft Networks client driver. This driver is displayed as the currently selected primary logon provider in list box 103 of FIG. 1. One skilled in the art will recognize that other methods for providing a logon user interface are possible, as well as other user interfaces other than dialog boxes. For example, a resource file or an API could be provided by the underlying operating system and made available to the various client network drivers to be used for building their logon user interfaces. In FIG. 3, dialog window 301 contains three identification information fields. User name field 302 is an edit field for entering the user's identity. Password field 303 is an edit field for entering a password corresponding to the user name displayed in field 302. Domain field 304 is an edit field which determines the authenticating authority that is to validate the password entered in field 303. The entries in the user name and password fields are authenticated to provide secure access to the network services provided by the particular network client driver that is currently displaying the dialog (in this case, the client for Microsoft Networks driver services).

In prior systems, if a computer system was connected to several different networks via different network client drivers, then the user would be confronted with a separate logon user interface for each network to which the user attempted access. Embodiments of the present invention provide a mechanism for enabling a user to choose which logon user interface is initially displayed and for minimizing the number of user interface interactions required when a computer system is connected to multiple heterogeneous networks (different types of networks, such as Banyan VINES or Netware). Heterogeneous networks typically use different protocols to communicate between the computer systems connected by the network and typically provide their own logon and authentication mechanisms. Thus, without a mechanism to control the flow of user interface interactions, the user would typically be confronted with many different and potentially confusing user interfaces.

Also, embodiments of the present invention minimize the number of user interface interactions when the computer system is not actively or successfully connected to devices or pseudo-devices, but is configured to support them. For example, if the user has selected from list box 103 in FIG. 1 a network client driver as the primary logon provider, but the computer system is not currently connected to the corresponding network or the connection has somehow failed, embodiments of the present invention will display the user interface corresponding to the Windows Logon code (a dialog similar to that shown in FIG. 2) or that of another logon provider instead of displaying the user interface of the designated primary logon provider.

In preferred embodiments, the methods and systems of the present invention are implemented on a computer system comprising a central processing unit, a display, a memory, and input/output devices. Preferred embodiments are designed to operate in an operating system environment such as the Microsoft Windows environment defined by Microsoft Corporation in Redmond, Wash. One skilled in the art will also recognize that embodiments of the present invention can be practiced in other operating system environments.

FIG. 4 is a block diagram of a general purpose computer for practicing preferred embodiments of the present invention. The computer system 400 contains a central processing unit (CPU) 401, a display screen (display) 404, input/output devices 403, and a computer memory (memory) 402. The network drivers, as well as the operating system code for producing the logon user interface shown in FIG. 2, preferably reside in the memory 402 and execute on at least one CPU such as the CPU 401. The operating system code for controlling the initialization of the various network connections when the computer system is powered on is shown as the Multiple Provider Router 406 ("MPR") executing in the memory 402. Two network drivers are shown as driver.sub.i 407 and driver.sub.j 408. These network drivers are invoked by the MPR 406 to authenticate access to the network services provided by the drivers. The input/output devices 403 is shown containing two network connections 409 and'410 and storage device 411.

The two network connections 409 and 410 are present to illustrate that preferred embodiments are operative in an environment where the computer system is connected to one or more networks and that these networks may be heterogeneous. One skilled in the art will appreciate that the methods of the present invention may be practiced on processing systems with varying architectures, including multi-processor environments, and on systems with hard wired logic. Also, one skilled in the art will realize that the present invention can be implemented in a stand-alone environment where other types of drivers are used to support secure access to the computing services provided.

In one aspect of the invention, a preferred embodiment provides several application programming interfaces ("APIs", or sets of routines) for carrying out the methods of the present invention. FIG. 5 is a block diagram of the software architecture of the present invention implemented in a network environment. FIG. 5 shows two programs 501 and 502 (e.g., application programs), a multiple provider router dynamic link library ("DLL") 503, and three network drivers 504, 505, and 506 as might reside in the memory 402 of the computer system 400 shown in FIG. 4. The multiple provider router DLL 503 stores the code for the multiple provider router ("MPR"), which is implemented by the local computer operating system. The MPR code implements a set of network APIs, which are network independent and can be used by programs 501 and 502 to communicate with the various network drivers presently configured on the computer system. These network APIs enable programs 501 and 502 to communicate over the various connected networks without requiring specific knowledge regarding the capabilities or the programming interfaces of the networks. The MPR code 503 routes a program's request received through the network APIs to the various configured network drivers by calling routines defined in a Network Service Provider Interface ("SPI"). (Recall that "network drivers" refers generically to the set of software components that provide access to the network and other network services.) The SPI is a programming interface defined by the operating system and implemented by the various network drivers that desire to be invoked by the MPR code 503. The operating system defines the SPI to enable the MPR code 503 to communicate with various types of network drivers without having to understand the particular nuances of each individual network driver. Thus, Network Driver.sub.A, Network Driver.sub.B, and Network Driver.sub.i 504, 505, and 506 all provide an implementation of the SPI routines that can be called by the MPR code 503 to communicate over Network A, Network B, and Network i.

One of the routines defined as part of the Network Service Provider Interface is a logon routine. This routine is invoked by the MPR code 503, in an order to be described, to authenticate identification information for access to the networks currently configured in the computer system. FIG. 6 is an overview flow diagram of the steps performed by the Multiple Provider Router code to authenticate identification information for access to the local computer system and to the current configured networks. The logon sequence shown in FIG. 6 uses a designated primary logon provider to collect identification information, authenticates this identification information for access to local computing services without displaying an additional interface and then invokes the logon routines provided by the SPI implementations of the other network drivers currently configured in the computer system. Specifically, in step 601, the MPR code invokes the logon routine of the designated primary logon provider (driver). As will be discussed with reference to FIG. 8, the primary logon provider, if it is actively and successfully connected to a network device, displays its logon user interface to collect identification information and then authenticates that information. In step 602, the MPR code attempts local system authentication of the identification information collected at step 601 to validate the user for access to computing resources protected by the operating system. In step 603, the MPR code determines whether local system authentication was successful and, if so, continues at step 605, else continues in step 604. In step 604, the MPR code determines that it must display its own logon user interface to collect additional identification information and returns to step 602 to reattempt local system authentication. Otherwise, in step 605, the MPR code invokes the logon routines of the other network drivers currently configured using the previously collected identification information, and returns. The logon routines of the other network drivers may be invoked serially, concurrently, or in any order. One skilled in the art will recognize that the previously collected information provided to the logon routines of the other network drivers can be either the identification information collected by the primary logon provider in step 601 or the identification information collected for the purposes of local system authentication in step 604. Alternatively, default identification information could be provided instead of or in addition to the previously collected identification information.

FIG. 7 is a detailed flow diagram of the logon sequence provided by a preferred embodiment of the MPR code. In steps 701-706, the MPR code invokes the primary logon provider's logon code to collect identification information and to authenticate it for access to the services provided by the primary logon provider. These steps correspond to step 601 of FIG. 6. Steps 707-711 perform local system logon procedure and correspond to steps 602-604 of FIG. 6. Steps 712-715 invoke the other configured logon providers to authenticate access to their services. These steps correspond to step 605 of FIG. 6.

Specifically, in step 701 the MPR code determines initial values for the identification information. These may be default values or values previously saved from the last time this logon sequence was executed. In step 702, the MPR code determines whether a primary logon provider has been designated other than the system logon code (shown as the "Windows Logon" code entry in FIG. 1). If such a primary logon provider exists, then the MPR code continues in step 703, else continues in step 707. In step 703, the MPR code calls the primary logon provider's logon routine to collect identification information, which is typically a user name, a password and a domain. The initial identification information is passed to the primary logon provider so that the primary logon provider can use the information as needed, for example, to prefill the fields of the logon dialog box shown in FIG. 3. A preferred embodiment of the logon routine defined in the SPI is discussed in detail with reference to FIG. 8. In step 704, the MPR code determines whether the invoked logon routine returned a cancellation status and, if so, returns, otherwise continues in step 705. (The invoked logon routine would return a cancellation status if, for example, the user pressed the cancel button in dialog box 301 in FIG. 3.) In step 705, the MPR code determines whether the invoked logon routine has returned a status that indicates that the primary logon provider is actively (and successfully) connected to a device (or pseudo-device) and, if so, continues in step 706, else continues in step 707. In step 706, the MPR code sets the current identification information to the values returned by the primary logon provider's logon routine. Otherwise, when the logon user interface of the primary logon provider was not displayed because the primary logon provider was not connected successfully to its corresponding device or when the primary logon provider is the system logon code, the current identification values used are the initial identification information set in step 701.

Steps 707-711 perform local system logon using the system logon code. In step 707, the MPR code attempts to "logon" to the local system (local system authentication) using either the initial identification information set in step 701 or the identification information collected by the primary logon provider in step 703 (or the information collected by the system logon code in step 709, as is discussed below). The local system logon mechanism involves authenticating the passed identification information for access to whatever computing services the operating system is protecting. For example, the local computer system may maintain a user profile file that is protected by a password and cannot be accessed by application programs until it is "unlocked" by the local system logon code. In step 708, the MPR code determines whether the local system authentication was successful and, if so, continues in step 712, else continues in step 709. In step 709, since the authentication using the previously collected identification information was not successful, the MPR code displays its own logon user interface to collect additional identification information. In step 710, the MPR code determines whether the user canceled out of this user interface and, if so, continues in step 711, else returns to step 707 to reattempt local system authentication with the newly collected identification information. Local system authentication is thus reattempted until either the user cancels out of the user interface or authentication is successful. In step 711, if the user has canceled out of the system logon user interface and if this is the first logon user interface displayed to the user, then the MPR code returns because no services are available. (If the system logon user interface is the first logon user interface displayed, then either a primary logon provider other than the system logon code was not designated or the primary logon provider is not actively or successfully connected.) Otherwise, even though the identification information has not been authenticated for local system computing service access, other services (such as network services) are potentially available, and thus the MPR code continues in step 712.

In steps 712-714, the MPR code loops through a list of logon providers invoking their logon routines to enable them to perform their authentication procedures. Specifically, in step 712, the MPR code gets the next logon provider from the list of configured logon providers (e.g., list box 103 in FIG. 1) skipping over the designated primary logon provider. In step 713, the MPR code determines whether there is another logon provider on the list to process and, if so, continues in step 714, otherwise continues in step 715. In step 714, the MPR code calls the logon routine of the currently selected logon provider from the list. One skilled in the art will realize that, although the loop of steps 712-714 is shown to invoke the other logon providers serially in a sequence, other implementations are possible and might provide efficiency benefits on other architectures. For example, the additional logon providers' logon routines may be invoked concurrently. Alternatively, there may be a static or dynamic ordering of the providers or a mixture of serial and concurrent invocation. For example, the providers may each have an associated priority and the list of providers ordered and invoked according to these priorities. In step 715, the MPR code sets the default identification information to the current identification information to be used the next time the MPR logon sequence is invoked, and returns.

FIG. 8 is a flow diagram of an example logon routine implemented by a logon provider. This figure illustrates a preferred implementation of the logon routine defined in the Network Service Provider Interface ("SPI") shown in FIG. 6. Any logon provider that implements the logon routine defined in the SPI can be designated as a primary logon provider, as was discussed with reference to FIG. 1. Different behaviors are provided by the logon routine with respect to displaying a logon user interface based upon whether the logon routine is called as the primary logon provider's logon routine or whether it is called as a supplemental logon provider's logon routine. In summary, the logon routine determines whether it should display a logon user interface to collect identification information, displays the logon user interface when needed, authenticates the collected identification information, and returns the authenticated identification information to the MPR code logon sequence shown in FIG. 7.

Specifically, in step 801, the logon routine determines whether the logon provider is currently connected to its corresponding device (or pseudo-device) and the connection has not failed and, if so, continues in step 802, else returns with a status indicating that no connection is available (or the connection has otherwise failed). In step 802, the logon routine determines whether the user has already logged on and, if so, returns a successful status, else continues in step 803. In step 803, the logon routine determines whether it is being called as the primary logon provider's logon routine and, if so, continues in step 807, else continues in step 804. In step 804, when the logon routine is invoked as a supplemental logon provider routine, the logon routine determines whether a password has been cached for its services and, if so, continues in step 806, else continues in step 805. Passwords are cached, for example, when a network driver asks the user whether it should remember a previously entered password for future invocations to avoid prompting the user again. In step 806, if a password has been cached, then this cached password is used in step 809. Otherwise, if no password has been cached, the logon provider will use identification information (user name and password) supplied in an input parameter to the logon routine as shown in step 805. The logon routine then continues in step 809. If, in step 803, the logon routine instead determines that it has been invoked as the primary logon provider's logon routine, then in step 807 the logon routine displays its logon user interface. In step 808, the logon routine determines whether the user canceled out of this user interface and, if so, returns with a status of cancellation, else continues in step 809.

In step 809, the logon routine authenticates the identification information either collected from the logon code's user interface in step 807, from the identification information supplied in an input parameter in step 805, or from the password cache as described in step 806. The authentication procedure is specific to each logon provider and may be as simple as validating the collected information against a password file. The authentication procedure authorizes access to whatever services are provided by that particular logon provider. In step 810, the logon routine determines whether the authentication procedure was successful and, if so, continues in step 811, else returns to step 807 to display a logon user interface to collect additional identification information in order to reattempt the authentication procedure. The authentication procedure is reattempted until either the authentication is successful or until the user cancels out of the user interface. In step 811, the logon routine determines whether it is invoked as the primary logon provider's logon routine and, if so, continues in step 812, else returns with a successful status. In step 812, the routine sets an output parameter to indicate the collected and authenticated identification information and returns a successful status.

One security issue that surfaces with the embodiment discussed with reference to FIGS. 7 and 8 is that any code that is able to install itself as a logon provider will be passed the user's identification information by the MPR logon sequence. Thus, code could be installed to store the passed identification information and to use it for unauthorized purposes. One skilled in the art will recognize that there are different mechanisms available for preventing such unwanted behavior. In one embodiment, the operating system verifies that each logon provider is a legitimate (or known) logon provider. This verification of the logon providers can be done at load time, at configuration time, or at some other time such as right before identification information is passed. One such verification technique is to use digital signature techniques, such as those described in Schneier, B., Applied Cryptography, Wiley & Sons, Inc., N.Y., 1994. According to this embodiment, the logon providers are passed identification information only after the logon providers have been previously verified by the operating system.

The preferred embodiments discussed are also applicable to logon providers that are not network drivers. One skilled in the art will recognize that any code that supports a logon routine as described with reference to FIG. 8 can be configured as a logon provider. For example, if code is provided in a DLL that provides a secure front end to a database and supports the logon routine discussed with reference to FIG. 8, then the MPR logon sequence discussed with reference to FIGS. 6 and 7 can invoke the logon routine when the DLL code is designated as the primary logon provider. Also, the MPR logon sequence can invoke a non-network logon provider's logon routine as a supplemental logon provider in step 605 of FIG. 6 and steps 711-713 of FIG. 7. Thus, the user interface for logon to an entire computer system (whether connected or not to a network) can be replaced by providing logon provider code with a logon routine conforming to the SPI definition discussed with reference to FIG. 8.

One skilled in the art will also recognize that other embodiments for replacing the computer system logon user interface are possible. For example, in another network environment, the code to provide network services (the network driver code) can be separate from the code used to display a logon user interface and to authenticate the user for access to the computer system. Specifically, a separate code module, which is invoked whenever logon is performed, is provided to implement the initial (system) logon and authentication procedure for the computer system that is invoked during power up. In this embodiment, the user interface for system logon is replaced by linking in the desired logon user interface (e.g., at run time). For example, the code module with the desired logon user interface can be copied into or renamed as the logon and authentication module. According to this embodiment, the MPR code links in the appropriate logon user interface module to provide the initial user interface for collecting the identification information instead of invoking a network driver as the primary logon provider. Using this alternative embodiment, each network driver is independent of the user interface used to authenticate access to a network or to the computer system. Once access has been granted, the identification information can be passed on to the other network drivers as indicated in FIGS. 6 and 7.

As an example of this alternative embodiment, a logon user interface that provides card reader access to the computer system could replace the standard operating system logon dialog shown in FIG. 2. A third party developer could provide such a replacement interface by coding a separate DLL which is then linked appropriately into the MPR code. A card reader user interface may provide additional security by requiring an intended user to enter a personal identification number.

The preferred embodiment discussed with reference to FIGS. 6-8 can also be used to provide a local computer system access to a network during the local system logon process. This capability is useful, for example, when user profiles (information specific to a user) are stored on a server node on the network and the user profile information is needed to authenticate the user for access to the local computer system. Such an architecture might be useful to enable a network system administrator to control which users have access to which systems. According to this embodiment, once the MPR code has invoked (successfully) the primary logon provider's logon routine, the MPR code can then access files on the network accessible through the primary logon provider.

Although the present invention has been disclosed and described in terms of preferred embodiments, it is not intended that the invention be limited to such embodiments. Modifications within the spirit of the invention will be apparent to those skilled in the art. The scope of the present invention is defined by the claims which follow.