Methods, devices, and computer program products for discovering authentication servers and establishing trust relationships therewith

Using an authentication server to discover one or more additional authentication servers and to dynamically establish a trust relationship with the one or more additional authentication servers. The authentication server searches for the one or more additional authentication servers to discover one or more sources of authentication tokens, and inspects an incoming authentication request from the one or more additional authentication servers to determine if the request is carrying one or more authentication tokens from a newly discovered realm. Once the authentication server determines a newly discovered realm to be trustworthy, the authentication server receives a directory schema from the newly discovered realm and compares the received directory schema with a known directory schema retrieved by the authentication server to identify an intersection of the received directory schema and the known directory schema. The authentication server uses the intersection to identify a primary key, and to identify any unique information that is specific to either the authentication server or the newly discovered realm.

TRADEMARKS

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to authentication servers and, more particularly, to discovering authentication servers and establishing trust relationships therewith.

2. Description of Background

Federated identity allows a user of a computing device to log on to a given website or server, have their identity authenticated, and then permit that website or server to vouch for their identity while they try to gain access to other websites, servers, or networks. For example, employees who need to look up information regarding heath care benefits typically have to access a third-party website by entering a log-on name and a password specific to that third-party website. However, federated identity enables these employees to automatically link to the third-party website without the necessity of logging onto the site via a site-specific log-on name and password. One illustrative example of federated security software is Tivoli Federated Identity Manager (TFIM). TFIM is compatible with several federated identity standards and specifications, including Liberty, Security Assertion Markup Language (SAML), Web Services Federation (WS-Federation), WS-Security and WS-Trust. TFIM uses a federated identity manager that allows users to sign on for internal and external services throughout a company and to contact any of the company's partners authorized to use TFIM.

In order to implement federated identity procedures, existing authentication systems must be explicitly federated together using federated security software such as TFIM. However, when existing federated security software packages are utilized, intra-domain relationships between previously separate authentication registries must be statically defined by an administrator, even in the context of TFIM. Statically defining these relationships requires significant administrative overhead for aligning policies from different domains and does not facilitate dynamic security mechanisms. A need therefore exists for improved methods by which federated identity procedures may be implemented. A solution that addresses, at least in part, the above and other shortcomings is desired.

SUMMARY OF THE INVENTION

Embodiments of the invention include methods for using an authentication server to discover one or more additional authentication servers and to dynamically establish a trust relationship with the one or more additional authentication servers. The methods include the authentication server searching for the one or more additional authentication servers to discover one or more sources of authentication tokens, and inspecting an incoming authentication request from the one or more additional authentication servers to determine if the request is carrying one or more authentication tokens from a newly discovered realm. If the request is carrying one or more authentication tokens from the newly discovered realm, then the authentication server determines whether or not the newly discovered realm is trustworthy by initiating communications with at least one trusted authentication server to ascertain whether or not there is an existing trust relationship between the at least one trusted authentication server and the newly discovered realm. If there is an existing trust relationship between the at least one trusted authentication server and the newly discovered realm, then the authentication server determines that the newly discovered realm is trustworthy. If there is not an existing trust relationship between the at least one trusted authentication server and the newly discovered realm, then the authentication server determines that the newly discovered realm is not yet trustworthy, and one or more attempts are made to use a plurality of additional authentication tokens to validate information provided by the newly discovered realm before accepting any authentications from the newly discovered realm. The authentication server determines that the not yet trustworthy newly discovered realm is trustworthy after a plurality of correct authentication tokens are received from the newly discovered realm. Once the authentication server determines a newly discovered realm to be trustworthy, the authentication server receives a directory schema from the newly discovered realm and compares the received directory schema with a known directory schema retrieved by the authentication server to identify an intersection of the received directory schema and the known directory schema. The authentication server uses the intersection to identify a primary key, and to identify any unique information that is specific to either the authentication server or the newly discovered realm.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, details are set forth to provide an understanding of the invention. In some instances, certain software, circuits, structures and methods have not been described or shown in detail in order not to obscure the invention. The term “data processing system” is used herein to refer to any machine for processing data, including the client/server computer systems and network arrangements described herein. The present invention may be implemented in any computer programming language provided that the operating system of the data processing system provides the facilities that may support the requirements of the present invention. The invention may be implemented with software, firmware, or hardware, or any of various combinations thereof.

FIG. 1is an architectural block diagram showing an illustrative operational environment for the present invention.

FIGS. 2A and 2Btogether comprise a flowchart setting forth a first exemplary method for discovering authentication servers and establishing trust relationships therewith.

FIG. 3is a flowchart setting forth a second exemplary method for discovering authentication servers and establishing trust relationships therewith.

FIG. 4is a flowchart setting forth a third exemplary method for discovering authentication servers and establishing trust relationships therewith.

FIG. 5is a flowchart setting forth a fourth exemplary method for discovering authentication servers and establishing trust relationships therewith.

FIG. 1is a block diagram setting forth an illustrative operational environment in which the present invention is employed. In particular, a plurality of authentication servers in the form of nodes100.1through100.nare interconnected over a network104. Nodes100.1through100.nperform data input/output (I/O) operations on a storage device through a server node or over a local path. Nodes100.1through100.nare operably coupled to network104through one or more adapters, cables, switches, or any of various combinations thereof.

In preferred embodiments of the present invention, each node100.irepresents an authentication server in the form of a processor node capable of communicating with other processor nodes using the publicly defined Transmission Control Protocol/Internet Protocol (TCP/IP) messaging protocol. While this protocol is referred to as an Internet Protocol, it should be noted that use of this term herein does not imply the existence of any Internet connection, nor does it imply dependence upon the Internet in any way. It is simply the name of a conveniently used, well characterized communication protocol suitable for use within a connected network of data processing nodes.

Each node100.imay include one or more Central Processing Units (CPUs), some or all of which share memory with one another. This memory can be implemented using any computer readable storage medium such as electronic memory, magnetic memory, optical memory, or any of various combinations thereof. One or more of these CPUs are capable of implementing an operating system. Each node100.imay be connected locally to a non-volatile storage device such as a Direct Access Storage Device (DASD) unit or other similar storage device200.i, where i is an integer greater than or equal to 2, but less than or equal to n. Storage device200.itypically comprises a rotating magnetic disk storage unit, sometimes referred to as a disk drive. However, the scope of the present invention includes any nonvolatile storage mechanism capable of holding data files. The number n of nodes100.iis not critical. Furthermore, not everything operably coupled to network400has to be a data processing node. A plurality of DASD storage devices300.1through300.mare connected to network400using, for example, a network adapter300for maintaining communication between DASD storage devices300.1to300.mand network400.

The nodes100.imay contain additional software and hardware, a description of which is not necessary for understanding the invention. One or more of the nodes100.ihas stored therein data representing sequences of instructions which, when executed, cause the methods described hereinafter to be performed. Thus, one or more of the nodes100.iinclude computer executable programmed instructions for directing the system ofFIG. 1to implement any of the embodiments of the present invention.

The programmed instructions may be embodied in at least one hardware, firmware, or software module resident in a memory associated with the one or more Central Processing Units (CPUs) of one or more nodes100.i. This memory can be implemented using any computer readable storage medium such as electronic memory, magnetic memory, optical memory, or any of various combinations thereof. Alternatively or additionally, the programmed instructions may be embodied on a computer readable medium (such as a CD disk or floppy disk) which may be used for transporting the programmed instructions to the memory of the node100.i. Alternatively or additionally, the programmed instructions may be embedded in a computer-readable, signal or signal-bearing medium that is uploaded to the node100.iby a vendor or supplier of the programmed instructions, and this signal or signal-bearing medium may be downloaded through an interface to the node100.ifrom the network400by end users or potential buyers.

FIGS. 2A and 2Btogether comprise a flowchart setting forth a first exemplary method for discovering authentication servers and establishing trust relationships therewith. More specifically, the method includes using an authentication server to discover one or more additional authentication servers and to dynamically establish a trust relationship with the one or more additional authentication servers. The procedure ofFIGS. 2A and 2Bcommences at block201(FIG. 2A) where the authentication server searches for the one or more additional authentication servers to discover one or more sources of authentication tokens. Next, at block203, the authentication server inspects an incoming authentication request from the one or more additional authentication servers in order to determine if the request is carrying one or more authentication tokens from a newly discovered realm. At block205, a test is performed to ascertain whether or not the request is carrying one or more authentication tokens from the newly discovered realm. The negative branch from block205loops back to block201.

If the request is carrying one or more authentication tokens from the new realm as determined at block205, then the authentication server determines whether or not the new realm is trustworthy by initiating communications with at least one trusted authentication server to ascertain whether or not there is an existing trust relationship between the at least one trusted authentication server and the new realm (block207). This is similar to trusting a Pretty Good Privacy (PGP) key because it is signed with a trusted third party key. Further information regarding use of PGP keys is described in chapter 1 of a document entitled “Introduction to Cryptography”, copyright © 1990-1999 Network Associates, Inc., published on the Internet, and incorporated by reference herein in its entirety.

At block209, a test is performed to ascertain whether or not there is an existing trust relationship between the at least one trusted authentication server and the newly discovered realm. The affirmative branch from block209leads to block211, and the negative branch from block209leads to block213. At block211, if there is an existing trust relationship between the at least one trusted authentication server and the newly discovered realm, then the authentication server determines that the newly discovered realm is trustworthy. At block213, if there is not an existing trust relationship between the at least one trusted authentication server and the newly discovered realm, then the authentication server determines that the newly discovered realm is not yet trustworthy, and at block215, one or more attempts are made to use a plurality of additional authentication tokens to validate information provided by the newly discovered realm before accepting any authentications from the newly discovered realm. The authentication server determines that the not yet trustworthy newly discovered realm is trustworthy (FIG. 2B, block217) after a plurality of correct authentication tokens are received from the newly discovered realm.

Block219is performed after either of blocks217or211are performed. At block219, once the authentication server determines a newly discovered realm to be trustworthy, the authentication server receives a directory schema from the newly discovered realm and compares the received directory schema with a known directory schema retrieved by the authentication server to identify an intersection of the received directory schema and the known directory schema. The authentication server uses the intersection to identify a primary key, and to identify any unique information that is specific to either the authentication server or the newly discovered realm (block221). Thus, for example, if each of a plurality of newly discovered realms are deemed trustworthy, the authentication server contacts each realm and compares the directory schemas to determine if there are any correlation points or information that is unique (“Do you have some information that I don't that will be useful to me and do we have some common information that could be used as a primary key to establish the user's identity?”). If and when primary keys are identified, the authentication servers can locate the unique information per-user specific to each server. Then, as discussed hereinafter, if there is information unique to a server then when the authentication server receives information from the user that it cannot validate, it can pass the data validation request to an alternate server.

The authentication server receives an authentication request, along with authentication data associated with the request, the authentication data including an authentication token that the authentication server cannot validate (block223). The authentication server passes the authentication request to the one or more additional servers of the newly discovered realm (block225).

Optionally, block201includes the authentication server actively seeking out other authentication servers via service location protocol (SLP) or another service discovery method. Optionally, block203includes the authentication server inspecting incoming authentication requests to determine if the request is carrying authentication tokens from other newly discovered or unknown realms, and then adds those realms to a discovery list.

FIG. 3is a flowchart setting forth a second exemplary method for discovering authentication servers and establishing trust relationships therewith. The procedure commences at block301where the authentication server initiates discovery. At block303, the authentication server locates a data source associated with a secondary authentication server. The primary and secondary servers decide how much to trust each other (blocks305and307). If trust is established, then the procedure ofFIG. 3continues to block309where the primary and secondary authentication servers exchange schemas and use an intersection of the schemas as a primary key (email, for instance). When an authentication request is received at the primary authentication server (blocks311and313), data that cannot be verified by the primary authentication server is passed along to the secondary authentication server for verification (block315). The secondary authentication server attempts to validate the authentication data and returns a result of the attempt to the primary authentication server (block317). The actual private data need not be shared, only the result. At block319, the primary authentication server uses the results obtained in blocks313and317to make a decision as to whether or not to grant the authentication request.

FIG. 4is a flowchart setting forth a third exemplary method for discovering authentication servers and establishing trust relationships therewith. At block401, a primary authentication server initiates discovery. Next, at block403, the primary authentication server locates a data source associated with a secondary authentication server. The primary and secondary authentication servers decide how much to trust each other (blocks405and407). If trust is not established but possible, then the program advances to block409where the primary and secondary authentication servers exchange schemas and use the intersection of the schemas as a primary key (email, for instance).

When an authentication request is received with data that can be verified by the primary authentication server (blocks411and413), it is also queried against the secondary authentication server (blocks415and417) and answers are used by the primary authentication server (block418) to determine whether the secondary authentication server is trustworthy over time. As trust grows between the primary and secondary authentication servers, the procedure ofFIG. 4may be replaced or supplanted by the procedure ofFIG. 3. Next, at block419(FIG. 4), the primary authentication server uses the results of blocks413and417to make a decision as to whether or not to grant the authentication request.

FIG. 5is a flowchart setting forth a fourth exemplary method for discovering authentication servers and establishing trust relationships therewith. Basically, an authentication server may choose not to trust a newly discovered realm. However, even when not trusting the newly discovered realm, it may be possible to exchange user information such that the identity of a user can be known to both the authentication server and the newly discovered realm, but to not trust the newly discovered realm to authenticate user sessions correctly. This would be halfway to single sign on—a user crossing between realms is known to the newly discovered realm, but the users have to authenticate themselves before obtaining access.

The procedure ofFIG. 5commences at block501where the authentication server initiates discovery. Next, at block503, the server locates a data source associated with a secondary authentication server. At block505, the primary and secondary authentication servers decide not to trust each other. The primary and secondary authentication servers exchange schemas (block507) and use the intersection of the schemas as the primary key (email, for instance). An authentication request arrives at the primary authentication sever (block509), wherein the request contains an authentication token for an existing known identity from the secondary authentication server (i.e., an untrusted server). The primary authentication server authenticates the request locally (block511), such that a user does not have to identify himself or herself again.