Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted auth

What is claimed is:

1. In a data processing system including a client mechanism, a server mechanism including a server resource, and an authorization mechanism, the authorization mechanism including a directory server for storing and providing access rights of the client mechanism to the server resource and the client mechanism generating operation requests for operations to be performed by the server with respect to the server resource, wherein the client mechanism generates a request to the authorization mechanism for an authorization ticket to the server resource and the authorization mechanism responds to a request for an authorization ticket by returning an authorization ticket containing an identification of the client, the authorization ticket being encrypted with an encryption key derived from the password of the server, the client mechanism providing the authorization ticket to the server mechanism is associated with an operation request, the server mechanism decrypting the authorization ticket with the server password and using the client identification to obtain the client access rights of the client mechanism to the server resource, an improved authorization mechanism, comprising:

a directory server for storing access rights of the client mechanism and information regarding the client mechanism and required by the server mechanism in executing the operation request,

a client mechanism for generating a request for an authorization ticket to the server mechanism, the request for an authorization ticket including an identification of the client mechanism,

an authorization mechanism for generating a corresponding authorization ticket wherein the authorization ticket includes the access rights of the client mechanism and the information regarding the client mechanism and required by the server mechanism in executing the operation request and is encrypted with an encryption key derived from the password of the server, and

the client mechanism being responsive to the authorization ticket for sending the authorization ticket to the server mechanism in association with the operation request, and

a server mechanism for decrypting the authorization ticket with the server mechanism password and obtaining directly the access rights of the client mechanism to the server resource and the information regarding the client mechanism and required by the server mechanism in executing the operation request, wherein

the client information including the client access rights are stored in the directory server in fields identified by generic field tags,

the authorization ticket request generated by the client mechanism identifies the client information by tag names identifying the fields containing the required client information,

the requested information is stored in the encrypted authorization ticket in fields identified by the corresponding tag names, and

the server mechanism reads the client information from the decrypted authorization ticket by parsing the decrypted authorization ticket with the tag names of the fields containing the necessary client information.

2. In a data processing system including a client mechanism, a server mechanism including a server resource, and an authorization mechanism, the authorization mechanism including a directory server for storing and providing access rights of the client mechanism to the server resource and the client mechanism generating operation requests for operations to be performed by the server with respect to the server resource, wherein the client mechanism generates a request to the authorization mechanism for an authorization ticket to the server resource and the authorization mechanism responds to a request for an authorization ticket by returning an authorization ticket containing an identification of the client, the authorization ticket being encrypted with an encryption key derived from the password of the server, the client mechanism providing the authorization ticket to the server mechanism is associated with an operation request, the server mechanism decrypting the authorization ticket with the server password and using the client identification to obtain the client access rights of the client mechanism to the server resource, an improved method for providing client information to the server mechanism, comprising the steps of:

storing client information including access rights of the client mechanism and information regarding the client mechanism and required by the server mechanism in executing an operation request in the directory server in fields identified by generic field tags,

in the client mechanism and in response to a request from a user for an operation by the server mechanism, generating a request for an authorization ticket to the server mechanism, the request for an authorization ticket including an identification of the client mechanism and including identifying the client information in the authorization ticket request by tag names identifying the fields containing the required client information,

in the authorization mechanism and in response to the request for an authorization mechanism, generating a corresponding authorization ticket wherein the authorization ticket includes the access rights of the client mechanism and the information regarding the client mechanism and required by the server mechanism in executing the operation request and is encrypted with an encryption key derived from the password of the server, including storing the requested information in the encrypted authorization ticket in fields identified by the corresponding tag names

by operation of the client mechanism, sending the authorization ticket to the server mechanism in association with the operation request, and

in the server mechanism, decrypting the authorization ticket with the server mechanism password, parsing the decrypted authorization ticket with the tag names of the fields containing the necessary client information to obtain the client information, and obtaining directly the access rights of the client mechanism to the server resource and the information regarding the client mechanism and required by the server mechanism in executing the operation request.

3. In a data processing system including a client mechanism, a server mechanism including a server resource, and an authorization mechanism, the authorization mechanism including a directory server for storing and providing access rights of the client mechanism to the server resource and the client mechanism generating operation requests for operations to be performed by the server with respect to the server resource, wherein the client mechanism generates a request to the authorization mechanism for an authorization ticket to the server resource and the authorization mechanism responds to a request for an authorization ticket by returning an authorization ticket containing an identification of the client, the authorization ticket being encrypted with an encryption key derived from the password of the server, the client mechanism providing the authorization ticket to the server mechanism is associated with an operation request, the server mechanism decrypting the authorization ticket with the server password, an improved authorization mechanism, comprising:

a directory server for storing access rights of the client mechanism,

a client mechanism for generating a request for an authorization ticket to the server mechanism, the request for an authorization ticket including an identification of the client mechanism,

an authorization mechanism for generating a corresponding authorization ticket wherein the authorization ticket further includes the access rights of the client mechanism and is encrypted with an encryption key derived from the password of the server, and

the client mechanism being responsive to the authorization ticket for sending the authorization ticket to the server mechanism in association with the operation request, and

a server mechanism for decrypting the authorization ticket with the server mechanism password and obtaining the identification of the client and the access rights of the client mechanism to the server resource directly from the authorization ticket.

4. The improved authorization mechanism of claim 3, wherein:

the directory server further stores information regarding the client mechanism and required by the server mechanism in executing the operation request,

the authorization ticket request generated by the client mechanism further includes an identification of the client information required by the server mechanism in executing the operation request,

the authorization mechanism is responsive to the ticket request for placing the requested information into the encrypted authorization ticket, and

the server mechanism decrypts the authorization ticket and reads the information for executing the operation request directly from the decrypted authorization ticket.

5. In a data processing system including a client mechanism, a server mechanism including a server resource, and an authorization mechanism, the authorization mechanism including a directory server for storing and providing access rights of the client mechanism to the server resource and the client mechanism generating operation requests for operations to be performed by the server with respect to the server resource, wherein the client mechanism generates a request to the authorization mechanism for an authorization ticket to the server resource and the authorization mechanism responds to a request for an authorization ticket by returning an authorization ticket containing an identification of the client, the authorization ticket being encrypted with an encryption key derived from the password of the server, the client mechanism providing the authorization ticket to the server mechanism is associated with an operation request, the server mechanism decrypting the authorization ticket with the server password, an improved method for providing client information to the server mechanism, comprising the steps of:

storing access rights of the client mechanism in the directory server,

by operation of the client server and in response to a user request, generating a request for an authorization ticket to the server mechanism, the request for an authorization ticket including an identification of the client mechanism,

in the authorization mechanism and in response to a request for an authorization ticket, generating a corresponding authorization ticket wherein the authorization ticket further includes the access rights of the client mechanism and is encrypted with an encryption key derived from the password of the server, and

by operation of the client mechanism, sending the authorization ticket to the server mechanism in association with the operation request, and

in the server mechanism, decrypting the authorization ticket with the server mechanism password and obtaining the identification of the client and the access rights of the client mechanism to the server resource directly from the authorization ticket.

6. The improved method for providing client information to the server mechanism of claim 5, further comprising the steps of:

storing information regarding the client mechanism and required by the server mechanism in executing the operation request in the directory server,

by operation of the client mechanism and in response to the request by the user for an authorization ticket, including an identification of the client information required by the server mechanism in executing the operation request in the authorization ticket request,

by operation of the authorization mechanism and in response to the request for an authorization ticket, placing the requested information into the encrypted authorization ticket, and

in the server mechanism, decrypting the authorization ticket and reading the information for executing the operation request directly from the decrypted authorization ticket.

Description Submit all comments and votes

CROSS REFERENCES TO RELATED APPLICATIONS

This patent application is related to: U.S. patent application Ser. No. 08/143,162, filed on Nov. 3, 1991, by Edward A. Russel et al. for "Client/Server Connection Sharing".

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for establishing and executing remote procedure calls between clients and servers in a data processing system and, more particularly, to client connection methods and apparatus for sharing communications connections between clients and to server method and apparatus for pooling of server worker processes.

BACKGROUND OF THE INVENTION

Data processing systems are frequently comprised of a plurality of client platforms, such as personal workstations or personal computers, connected through networks to one or more server platforms which provide data related services to the application programs executing on the client platforms. The data related services may include data storage and retrieval, data protection, and electronic mail services and such services may be provided to the users from both local servers and from remote servers which are networked to a user's local server.

A number of problems arise from such system configurations, however, one being that the client and server platforms are frequently based upon different operating system. For example, the client platforms may use Microsoft Windows and application programs designed to use Microsoft Windows while the server platforms may be based upon the UNIX operating system. As such, the connection and communications between the client platforms and the server platforms must be of a nature to be compatible with both types of operating systems and associated application and services programs.

Other problems arise from the inherent limitations of the connection and communications facilities associated with the client applications and, as a separable problem, with the inherent limitations of the server programs, such as the data storage and retrieval programs executing in the server platforms. These problems severely limit the capabilities of the client platforms and server platforms to communicate and to execute data storage and retrieval operations.

Referring first to the client platforms, client platforms are frequently limited in the number of network connections that they can support while there is traditionally one network connection for each client application, even if the connections are to the same server task. This in turn rapidly uses up the available client connections that can be supported by the client platform and results and a significantly slower startup time for each application then it attempts to connect to a server as a given client application may have to wait until a connection is established.

In addition, certain applications, such as those using Microsoft Windows, are pseudo multitasking rather than true multitasking, so that only the application currently having the operating system context can send and receive messages, and are non-preemptive, so that the current application will complete all message operations before passing the context to another application, so that only one application may make use of the connections at a time. Still further, such applications may be synchronous in that they will send a message or a request for an operation and then will wait until a response is received before executing a next operation. Therefore, not only are the available connections rapidly used up, but a given application may significantly delay other applications access to the available connections by forcing the other applications to wait until the application having a connection completes all of its operations.

One solution of the prior art to this problem has been to provide a connection sharing architecture, usually based upon a semaphore mechanism used in common by the applications to indicate when a connection is free for use by another application. This approach, however, not only does not solve all of the problems of the prior art as described above, but places a further burden on the application programs in that each application program must know of the connection sharing mechanism and must operate with the mechanism. This, for example, requires each application to deal with semaphoring and to hold, or queue, requests until a connection is free.

Referring now to the server platforms, server platforms usually provide a server task which operates alone to service requests one at a time. This in turn requires that the server task queue or otherwise hold pending requests until the server task has completely finished with each prior request.

One solution of the prior art has been to start a new server task or process for each new connection to the server wherein each process handles requests only from it own connection. This approach, however, substantially increases connection startup times because a new server process must be started for each new connection. In addition, this approach uses server resources inefficiently because a server process is idle until a request appears on its connection and, because an individual connection in a client/server model typically does not have frequent activity, the associated server process will be idle most of the time.

Another solution of the prior art has been for the server to include a dispatcher task which performs preliminary operations upon each incoming request and then passes the parameters of the request through an interprocess communication facility to a worker task to process. This approach is limited, however, in that the number of operations that the dispatcher must perform for each request limits the number of requests that the dispatcher can process in a given time. That is, when the rate at which requests are submitted to the server exceeds the rate at which the dispatcher can process the requests, the delay time in responding to a given request will increase to the point where the response time of the server is unacceptable. As such, the rate at which requests are submitted to the dispatcher must be limited, for example, by limiting the number of connections supported by the dispatcher or by limiting the rate at which requests may be submitted through the connections. In addition, the dispatcher is not available to detect new requests while processing a current request, thereby requiring a queue mechanism to hold new requests for the dispatcher. These problems are compounded in that the request parameters frequently include addresses, thereby requiring the dispatcher task to perform address resolution operations and further slowing the processing of requests by the server.

Finally, yet other problems in systems of the prior art arise from providing system security, usually by checking the access authorizations of user to various system resources, such as databases and electronic mail services. For example, one well known and often used authorization mechanism of the prior art involves an authentication server and a directory server wherein the directory server stores the authorization rights of the clients to various system resources and a set of individual passwords for the clients and for the system resources. The client makes a request to the authentication server for an identification packet which identifies the client and the authentication server provides a corresponding identification packet containing an identification of the client and this identification packet is encrypted using the password of the server as the encryption key. The client then sends the identification packet to the server, which decodes the identification packet with its password to obtain the identification of the client and uses this client identification to access the directory server to obtain the authorization rights of the client. This approach, however, places substantial burdens on both the directory server and the server which has been accessed, due to the number of directory access operations. In addition, this approach presents serious potential security problems in that all servers must have access to the directory server and must therefore be trusted, so that a false server could penetrate system security.

SUMMARY OF THE INVENTION

The present invention is directed to a method and apparatus for use in a data processing system for providing authorization information for a client requesting access to a server resource in a server. The system includes a client mechanism, a server mechanism including a server resource, and an authorization mechanism.

The authorization mechanism includes a directory server for storing access rights of a client and a client mechanism for generating a request for an authorization ticket to the server. The request for an authorization ticket includes an identification of the client and is in association with an operation call to the server.

An authorization mechanism generates a corresponding authorization ticket wherein the authorization ticket includes the access rights of the client and is encrypted with an encryption key derived from the password of the server and the connection mechanism sends the authorization ticket to the server mechanism in association with the operation call. The server then decrypts the authorization ticket with the server password and obtains directly the access rights of the client to the server resource.

The directory server of the authorization mechanism further stores information regarding the client that required by the server in executing the operation call, including access rights information, and the authorization ticket request generated by the client mechanism further includes an identification of the client information required by the server in executing the operation call. The authorization mechanism is responsive to the ticket request for placing the requested information into the encrypted authorization ticket and the server decrypts the authorization ticket and reads the information required to execute the operation call directly from the decrypted authorization ticket, including the access rights of the client.

In another aspect of the present invention, the client information including the client access rights are stored in the directory server in fields identified by generic field tags. The authorization ticket request generated by the client mechanism identifies the client information by tag names identifying the fields containing the required client information and the authorization server stored the requested information in the encrypted authorization ticket in fields identified by the corresponding tag names. The server mechanism then reads the client information from the decrypted authorization ticket by parsing the decrypted authorization ticket with the tag names of the fields containing the necessary client information.

Other features, objects and advantages of the present invention will be understood by those of ordinary skill in the art after reading the following descriptions of a present implementation of the present invention, and after examining the drawings, wherein:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1. is a diagrammatic representation of the system of the present invention;

FIGS. 2A, 2B and 2C are diagrammatic representations of connection configurations supported by the system of the present invention;

FIG. 3 is a block diagram of a connection mechanism of the system of the present invention;

FIGS. 4A, 4B, 4C, 4D, 4E and 4F are control data structures used by the connection mechanism;

FIG. 5 is a block diagram of a server of the system of the present invention;

FIGS. 6A, 6B and 6C are control data structures used by the server;

FIG. 7 is a block diagram of an authorization mechanism of the system of the present invention; and;

FIGS. 8A and 8B are diagrams of authorization requests and authorization tickets of the authorization mechanism.

DETAILED DESCRIPTION

The following will first provide a general description of a system incorporating the present invention, and then will describe the component mechanisms of the system in detail, beginning with the connection mechanisms of the present invention, then describing the server mechanism and finally the security mechanism

A. Description of the Connection Mechanisms (FIGS. 1, 2A, 2B, 2C, 3, 4A, 4B, 4C, 4D)

The following will discuss the overall structure and operation of the connection mechanism of the present invention and will then discuss the basic connection configurations supported by the connection mechanism. The data structures used by the connection mechanism will then be discussed in further detail, followed by a discussion of the creation and deletion of connections and sessions by the connection mechanism and certain of the routines used in these operations. The execution of client operations through the sessions and connections will then be discussed in detail.

1. General Description of the Connection Mechanism (FIG. 1)

Referring to FIG. 1, therein is shown a general block diagram representation of the connection mechanisms provided by a System 10 incorporating the present invention. As shown therein, System 10 is comprised of a Client Platform (CLPT) 12 and a Server Platform (SVPT) 14 which may be one of one or more Server Platforms (SVPTs) 14 wherein there are one or more Clients 16 are residing on CLPT 12 and one or more Servers 18 residing on each SVPT 14 and wherein CLPTs 12 and SVPTs 14 are connected through one or more Connections 20.

Operations between Clients 16 and Servers 18 are executed through sessions associated with Connections 20 wherein, for purposes of the following discussions, a Connection 20 is defined herein as logical communication path between a CLPT 12 and a Server 18 and a session is defined as a logical association between a Client 12 and a Server 18. As is well understood in the art, Connections 20 may be provided both as local connections and as network connections, and, in the present example of an implementation of System 10, each Client 16 is an application program executing under control of a user and a single user may control one or more application programs, each of which will be a Client 16.

The connection mechanisms residing in CLPT 12 include a plurality of data structures which are used in the present invention for controlling and managing the sharing of Connections 20 among Clients 16. These data structures include a Client Data Structure (CLDS) 22 for identifying and managing the Clients 16 having currently executing or pending requests, a Connection Data Structure (CCDS) 24 for identifying and managing Connections 20, and a set of Session Data Structures (SSDSs) 26 relating Clients 16 to Connections 20.

As shown, CLDS 22 includes one or more Client Control Blocks (CLBs) 28 wherein each CLB 28 contains information regarding a corresponding Client 16 or Clients 16. CCDS 24 includes one or more Connection Control Blocks (CCBs) 30 wherein there is a CCB 30 for and corresponding to each Connection 20 to a Server 18 and each CCB 30 contains information regarding the corresponding Connection 20.

Finally, SSDSs 26 each include one or more Session Control Blocks (SSBs) 32 wherein each SSB 32 corresponds to a session between a Client 16 and the Server 18 that is to execute one or more operations the Client 16. Each SSB 32 is associated with a CLB 28, and thus a Client 16, and contains information regarding the corresponding session and identifying the Connection 20 through which the session is to be performed.

As will be described in detail in the following, each session and its SSB 32 is identified by a unique session identifier and each Client 16 operation which is to be executed through the Connection 20 involved in the session is "stamped" with the session identifier. SSBs 32 thereby relate each Client 16 with the Server 18 which is to perform an operation for the Client 16 and the Connection 20 through which the Client 16 operation is to be performed and session identifier "stamped" on each Client 16 operation associates each Client 16 operation with a corresponding session and thus with a corresponding Connection 20.

The client, connection and session data structures thereby allow a Client 16 to operate in terms of requests, calls or commands for operations to be performed for specified Servers 18. The connection mechanisms relate each Client 16 operation to a session and a Connection 20 that are identified,through the corresponding SSBs 32 and the CCBs 30, thereby converting each Client 16 operation into a session/connection relationship. The Clients 16 are thereby isolated and insulated from the client to connection relationship and need not deal with the complexities of the client to connection relationship, thereby reducing the burden on the Clients 16 and allowing the Client 16's normal internal mechanisms to generating requests, calls or commands to operate without modification. The connection mechanism also isolates the connection mechanism from Clients 16, thereby allowing the connection mechanism to share Connections 20 among the Clients 16.

2. Connection Configurations (FIGS. 2A, 2B and 2C)

Referring to FIGS. 2A, 2B and 2C, therein are represented three basic connection configurations supported by the connection mechanism of System 10 and referred to herein respectively as the shared connection configuration, the single connection configuration, and the connection pooling configuration. The connection mechanism is not, however, limited to these specific configurations and other configurations may be constructed using the general elements of the connection mechanism as described herein.

In the shared connection configuration represented in FIG. 2A, there is a single Session 34 for each Connection 20 and a single Connection 20 for each Server 18 while two or more Clients 16 may share a CLB 28 and the CLB 28 may be associated with two or more Sessions 34. The two or more Clients 16 will thus appear as a single Client 16 to a Session 34, because of the shared CLB 28, and may thus share the Connection 20 associated with the Session 34.

In the single connection configuration represented in FIG. 2B, there is again a single Session 34 for each Connection 20 and a single Connection 20 for each Server 18. While there may be two or more Sessions 34 associated with each CLB 20, there is a single CLB 20 associated with each Client 16. As a result, Connections 20 are not shared among Clients 16 and, while each Client 16 may have more than one Connection 20, each Connection 20 will be used by a single Client 16.

In the connection pooling configuration shown in FIG. 2C, there will be one CLB 28 for each Client 16 and there will be one or more Sessions 34 for each Client 16. There may, however, be more than one Connection 20 for each Server 18, and more than one Session 34 for each Connection 20, so that the Clients 16 share a pool of Connections 20 to each Server 18.

B. Detailed Description of the Connection Mechanisms (FIGS. 3, 4A, 4B, 4C, 4D, 4E and 4F)

The connection mechanism described above will perform several types of operations in response to corresponding operation calls from a Client 16. Three of these operations are related to the creation and deletion of connections to servers while another type is comprised of server operations, such as data read and write operations to be executed by a server on behalf of a client. It is to be understood that the specific form in which a Client 16 issues requests for operations to the connection mechanism will depend upon the particular native mechanisms of the Client 16 and that the requests issued by a Client 16 to the connection mechanism are referred to herein as operation calls for connection and session operations and for server operations for convenience in the following descriptions.

The following will first discuss the operation of connection mechanism operations related to the creation and deletion of connections and sessions between the clients and the servers at a general level. The operation of the connection mechanism will then be described in detail and this description will include detailed descriptions of the client, connection and session data structures created by the connection mechanism in response to operation calls by the clients, including those for server operations.

1. Initialize and Bind/Unbind Operations

The operations performed by the connection mechanism in creating and deleting connections and sessions between clients and servers in response to corresponding calls by the clients include the initialize, bind and unbind operations. The initialize operation initializes a user application as a Client 16 while the bind and unbind operations respectively bind the Client 16 to a server and unbind the Client 16 from the server, including establishing and deleting connections and sessions and opening and closing data objects in the server as necessary for the bind or unbind operation.

It should be noted that, having executed the initialize operation, a Client 16 may then issue one or more bind/unbind operation calls to establish and delete connections and sessions with servers and need not execute the initialize call again unless the user application has issued a quit call to remove itself as a Client 16. As will be described in the subsequent detailed description of the connection mechanism, a Client 16, having executed the initialize call to become a Client 16 and having executed a bind call to establish a connection and session to a server, may then issue calls for server operations through the connection and session for so long as the connection and session exist.

Bind and unbind operations may be either explicit operations or implicit wherein an explicit bind occurs when a Client 16 specifically requests to be bound to a server through a Connection 20. An implicit bind occurs when a Client 16 generates a call for an operation, such as opening a data object or a data read or write, which implicitly requires that the Client 16 be bound to a server through a Connection 20. The present connection mechanism tracks the numbers of such requests separately but, in an alternate embodiment, may track both types of request with a single count.

The specific sequence of steps performed in each of these operations will depend upon whether the connection mechanism is to operate in the shared connection configuration, the single connection configuration, or the connection pooling configuration and whether the connection data structures required to complete a given operation already exist or must be created.

Shared Connection Configuration:

The sequence of steps for each operation for the shared connection configuration are:

Initialize:

Determines whether a CLB 28 exists and, if not, creates a CLB 28. As described above, a CLB 28 is shared by two or more Clients 16 in this connection configuration and a CLB 28 may therefore already exist.

Explicit Bind:

Determines whether a CCB 30 and a SSB 32 exists for the connection and session and creates a CCB 30 and/or a SSB 32 as necessary if either or both do not already exist. Makes a call to the server to obtain a session identifier for the session if the SSB 32 did not already exist. Increments the explicit bind count for the session.

Implicit Bind:

Performs the same sequence of steps as for the explicit bind but makes a call to the server to open the data object, if necessary, and increments the implicit bind count for the session.

Explicit and Implicit Unbind:

The explicit and implicit unbind operations respectively decrement the explicit and implicit bind counts for the session and the implicit unbind also closes the data object. If both the explicit and implicit bind counts for a session go to zero for a given session, the CCB 30 and SSB 32 will be deleted. The CLB 28 will not be deleted when the CCB 30 and SSB 32 are deleted as there may be more than one client using the CLB 28. The CLB 28 is deleted upon a specific QUIT call from the last client using the CLB 28.

Single Connection Configuration:

The sequence of steps for each operation for the single connection configuration are:

Initialize:

As described above, in the single connection configuration there is a CLB 28 for each client. The steps executed by the connection mechanism for initialization of a client the single connection are the same as in the shared connection configuration except that the connection mechanism determines whether there is a CLB 28 already in existence for the individual client and creates a CLB 28 if a CLB 28 does not already exist for that client.

Explicit and Implicit Binds:

The steps executed for the explicit and implicit bind operations in the single connection configuration are the same as for the shared connection configuration except that the connection mechanism will create a CCB 30 and a SSB 32 for that individual client if a CCB 30 and a SSB 32 do not already exist for that client.

Explicit and Implicit Unbinds:

The ste