Authentication framework for managing authentication requests from multiple authentication devices

[0002] 1. Technical Field

[0003] The present invention relates generally to the field of distributed computer networks and, in particular, to providing an authentication framework for use in authenticating clients having a plurality of permitted authentication device types.

[0004] 2. Description of the Related Art

[0005] It is commonplace today for computer users to connect their machines to other computers, known as “servers,” throughout a network. The network may be a private network, such as a corporate intranet of networked computers that is accessible only to computer users within that corporation, or it may be a public network, such as the Internet. The Internet is a vast collection of computing resources, interconnected as a network, from sites around the world.

[0006] A user may connect his computer to a server using a “wireline” connection or a “wireless” connection. Wireline connections are those that use physical media such as cables or telephone lines, whereas wireless connections use media such as satellite links, radio frequency waves, and infrared waves. Many connection techniques can be used with these various media, including: using the computer's modem to establish a connection over a telephone line; using a local area network (LAN) card such as Token Ring or Ethernet; using a cellular modem to establish a wireless connection, and the like. The user's computer may be any type of computer processor having processing and communication capabilities. Traditionally, such devices include desktop, laptop and handheld computers.

[0007] Conventional user id and password schemes for controlling user access to network resources are well-known. Recently, it has been proposed to provide client workstations in a network with so-called “alternative” authentication devices for access control purposes. Such devices include, for example, “token cards” and “biometric” (e.g., finger, eye or voice print) scanners. Representative token card systems are available commercially from Security Dynamics (SecureID™) and Axent (Defender™). Numerous third parties provide biometric scanning systems. A representative patent illustrating a biometric personal identification system based on iris analysis is U.S. Pat. No. 5,291,560. While these devices provide significant advantages, each authentication device vendor has a different way of encoding input information and validating the user's identity. Thus, it has not been possible to enable existing client/server and Internet-based applications to incorporate such alternate authentication devices into their current authentication schemes without compromising server trust policies.

[0008] The present invention solves this problem.

[0009] An object of the present invention is to provide an authentication framework for use in authenticating clients having a plurality of permitted authentication device types.

[0010] Another object of this invention is to provide an authentication architecture that enables client-server and Internet-based applications to use alternate authentication devices, e.g., token cards and biometric devices.

[0011] It is a more specific object to provide an application server with the capability of managing authentication request traffic from a variety of clients having disparate authentication devices or schemes.

[0012] A still further object of this invention is to enable the application server to manage such authentication request traffic without having to verify specific authentication device data, which typically varies depending on the device type and vendor.

[0013] Yet another object of this invention is to provide an architecture by which current and future applications may support varied authentication devices without necessarily having to be rewritten.

[0014] Still another more general object of this invention is to provide a pluggable framework for authentication services.

[0015] In the preferred embodiment, the authentication framework of the present invention has three (3) basic elements. First, a given application client has an authentication device attached to it, and the device is one of a plurality of permitted authentication device types. Thus, for example, the device is a token card or a biometric reader. Second, an application server of the framework knows what types of devices and servers it trusts. Third, given device authentication servers merely verify that authentication device data is acceptable for authentication. The device authentication servers may comprise part of the framework or operate in association with the framework.

[0016] In operation, each given application client passes to the application server a request for authentication. The request includes a user id and device id identifying a respective client and an authentication device coupled thereto. The application server (if it trusts the device and has support for it) determines which device authentication server the request is intended, and then routes given authentication data to that server. If the device authentication server verifies that the authentication data is acceptable for authentication, an authorization token is returned to the client.

[0017] The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the Preferred Embodiment.

[0018] For a more complete understanding of the present invention and the advantages thereof, reference should be made to the following Detailed Description taken in connection with the accompanying drawings in which:

[0019] FIG. 1 is a block diagram of the basic components of the authentication framework of the present invention;

[0020] FIG. 2 is a simplified flowchart of a routine for processing a given authentication request;

[0021] FIG. 3 is a perspective view of a client workstation having an authentication device;

[0022] FIG. 4 is a state diagram illustrating in more detail the basic authentication method of the present invention.

[0023] FIG. 1 is a high level diagram of the basic components of the inventive authentication framework. The framework 10 includes three (3) basic components: an application server 12, a client 14 having an authentication device 16, and an authentication device server 18. Application server 12 is the primary component and is used to manage and route requests for authentication received by each of the many application clients 14. Each client 14 may have associated therewith a given authentication device 16. The device 16 (which may be a physical device, a software-based process, or both) is one of a plurality of authentication device types managed by the framework. A device type is said to be a “permitted” authentication device type after it is registered with the application server. In this way, new authentication devices or device types are pluggable into the framework.

[0024] Each device type typically has its own authentication device server 18. Thus, the framework has multiple authentication device servers 18 associated therewith. A given authentication device server may comprise part of the framework or be an adjunct thereto. As used herein, an authentication device “type” refers to devices that authenticate according to different paradigms (e.g., token cards vs. biometric readers) as well as devices of the same generic functionality provided from different sources (e.g., a first biometric reader from vendor A and a second biometric reader from vendor B).

[0025] The authentication devices supported by the framework may be quite varied. Thus, for example, the authentication devices may be conventional devices or schemes based on id/password or cryptographic protocols, or so-called “alternative” authentication devices. Such authentication devices include, for example, “token cards” and “biometric” (e.g., finger, eye or voice print) scanners. Representative token card systems are available commercially from Security Dynamics (SecureID™) and Axent (Defender™). The framework, of course, is not limited to any particular type of authentication device, as an object of this invention is to support any type of authentication device regardless of the authentication protocol.

[0026] The invention accomplishes this object by using the application server as a “traffic cop” or router to manage authentication requests from the various clients (having disparate authentication devices). The application server 12 knows what types of devices and device servers it trusts, and the individual device authentication servers preferably have just a simple function (with respect to the inventive scheme), namely, to verify (yes/no) that authentication device data is acceptable for authentication.

[0027] FIG. 2 is a flowchart illustrating the basic operation of the authentication framework. The routine begins at step 20 after the local authentication device initially processes the user's request. At step 22, the client 14 passes to the application server 12 authentication data from the device 16, as well as other identifying information including a user id. A test is then performed at step 24 to determine whether the authentication device or device type is supported. Typically, an authentication device or device type is supported if there is a device authentication server 18 available to the framework. A given device authentication server 18 typically registers with the application server for this purpose. If the result of the test at step 24 is negative, an appropriate response is returned to the client at step 26 indicating the access is denied. If, however, the result of the test at step 24 indicates that the required device authentication server is supported, the routine continues at step 28. At this time, the application server 12 forwards the authentication data and the user id to the server 16. At step 30, the server 16 processes the authentication data. A test is then done at step 32 to determine whether the authentication data is acceptable. This step may require contacting a separate application authentication server. If the outcome of the test at step 32 is negative, an appropriate message is returned to the application server 12 at step 34. The application server 12, at step 36, then notifies the client that access is denied. If, however, the test at step 32 has a positive result, the routine continues at step 38 to provide this indication to the application server 12. At step 40, the application server 12 obtains an authentication token for the user. This token is then returned to the user at step 42 to complete the processing.

[0028] A representative application server 12 is an IBM RS/6000 server comprising a PowerPC processor, the AIX® operating system, and a file or Web server program. A representative client is a personal computer that is x86-, PowerPC®- or RISC-based, that includes an operating system such as IBM® OS/2® or Microsoft Windows '95, and that includes a Web browser. Given device authentication servers typically are vendor-specific.

[0029] FIG. 3 is perspective view of a representative client machine 14, which is a computer workstation having an alternative authentication device. In this illustration, the computer is a workstation, such as a personal computer running one of many suitable operating systems such as IBM OS/2®, Windows '98 or Windows NT®. One of ordinary skill will appreciate that the computer may also be a notebook computer, a diskless computer, or a pervasive computing device (e.g., a personal digital assistant, smartphone or the like). In this illustration, the computer is controlled by the user using keyboard 52 and mouse 53. Main processing unit 51 houses the mother board providing the main operational aspects of the computer, as well as conventional storage devices (e.g., a hard drive, CD-ROM, floppy drive, etc.). A monitor 54 provides visual display. As also seen, the workstation is configured with a biometric (e.g., fingerprint) scanner 55. As noted above, other authentication devices or schemes may be used instead of biometric reader. One of ordinary skill will appreciate that the particular authentication device, in this case biometric scanner 55, includes an authentication controller 57 (illustrated in phantom). In operation, the authentication device reads or otherwise obtains data appropriate for the method of authentication. As noted above, typically, each authentication device vendor has a different way of encoding such data and validating the user. Thus, according to the invention, information generated by the authentication controller is provided to the authentication framework for further processing as will now be described.

[0030] FIG. 4 is a state diagram illustrating how the authentication framework is used. It is assumed that the client has obtained the authentication data from its associated authentication device. The manner in which this is achieved, of course, is device-specific. As illustrated in FIG. 4, the client 14 then passes this data, together with a session key, K-session, to the application server 12. Preferably, the device data and the session key pair are encrypted with the application server's public key. The application server has an associated private key that, together with its public key, form a conventional public key cryptosystem. As seen in FIG. 4, preferably the string provided from the client 14 to the application server 12 also includes an identification of the device of device type (the “device-id”) as well as what user (the “id”) is requesting access. The id and device-id may be part of the encrypted string, if desired.

[0031] When the string is received, the application server 12 applies its private key to obtain the device data and the session key. The application server, however, does not perform an authentication function with respect to the data. Rather, it first determines whether the authentication device or device type of supported by the framework. This evaluation is typically effected by scanning a local database 15 (or by querying a network directory service) to determine if the device or device type has been registered with the framework. In particular, each authentication device may be registered with the framework, in which case a complete list of authentication devices is provided in the database 15. In larger networks, it may not be possible or desirable to maintain a list of all supported devices, in which case the database supports a list of authentication device types (e.g., token card readers, fingerprint readers, voiceprint readers from vendor A, voiceprint readers from vendor B, etc).

[0032] If the device or device type is recognized (as part of the framework), the application 12 server re-encrypts the device data with a key and, together with the user id, provides a string (comprising the encrypted device data and id “pair”) to a device authentication server 18. The particular device authentication server selected by the application server depends on the authentication device or its type. Typically, the application server 12 and each device authentication server share a given cryptographic protocol. Alternatively, a secure link (e.g., an https connection) may be used. That protocol determines the key value. The id value is provided because, typically, the device authentication server must also know the identity of the user to complete the authentication process.

[0033] The device authentication server 18 then verifies the authentication data and provides a simple Yes or No response back to the application server. Preferably, this response is signed (using a conventional digital signature scheme) with the key originally provided by the application server. Upon receipt, the application server processes the response as required and, as a result, knows the user is to be given access. It may then pass an authorization token back to the user, preferably encrypted in the session key.

[0034] If necessary, the application server obtains an authentication token from an application authentication server 17 as illustrated. That process is application-specific. After the user is authorized by the application authentication server, the authentication token is returned to the client, preferably encrypted in the session key. This completes the processing.

[0035] The above-described scheme thus provide a generic authentication framework. A plurality of device authentication servers are supported by the framework, preferably with at least one server providing authentication services for each type of authentication device supported. This allows any supported device authentication server to verify data from any supported authentication device on the network. The framework makes it easy to add support for new authentication devices by adding an associated authentication device server to the network and propagating the information regarding the new authentication device and server to the application server.

[0036] One of ordinary skill will also appreciate that there may be more than one application server. A plurality of such servers may be managed by one or more management servers to provide a robust and scaleable authentication framework for a large network. As discussed above, some or all of the message and response strings required by the inventive protocol may be communicated over a secure link as opposed to using encryption and digital signature schemes.

[0037] The present invention provides several advantages over the prior art. The invention provides an authentication framework for use in authenticating clients having a plurality of permitted authentication device types. The architecture enables client-server and Internet-based applications to use alternate authentication devices, e.g., token cards and biometric devices, as well as to integrate conventional authentication schemes such as id/password and crytographic protocols. The inventive framework includes an application server that manages authentication request traffic from a variety of clients having disparate authentication devices or schemes. The application server manages such request traffic without having to verify specific authentication device data, which typically varies depending on the device type and vendor. As a by-product, current and future applications may support varied authentication devices without necessarily having to be rewritten.

[0038] Moreover, the inventive framework provides authentication services in a manner that does not depend on or otherwise degrade individual authentication mechanisms. The invention enables new authentication devices or device types to be readily plugged into the framework. Moreover, the described embodiments enable multiple authentication devices to be utilized by an application without providing separate programming for each authentication device. In addition, because authentication data is stored on separate authentication device servers, security is enhanced.

[0039] The inventive framework preferably is implemented in software residing on the client, the application server, and the individual authentication device servers. The given functions described above thus may be implemented as a set of instructions (program code) in a code module resident in the random access memory of the computer. Until executed by the computer's processor, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network.

[0040] In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.

[0041] As used herein, the term “server” should also be broadly construed to mean a computer, computer platform, an adjunct to a computer or platform, or any component thereof. Of course, a “client” should be broadly construed to mean one who requests or gets the file, and “server” is the entity which downloads the file.