CA2102743C - Single step user authorization with included user information - Google Patents

Abstract

An authorization mechanism for providing authorization information for a client requesting access to a server resource in a server, including a directory server for storing client information required by the server in executing an operation call, including client access rights, and a generating a request for an authorization ticket to the server. The request for an authorization ticket includes an identification of the client and an identification of the client information required by the server and is in association with an operation call. The authorization mechanism generates an authorization ticket including the identified information and encrypted with an encryption key derived from the password of the server. The authorization ticket is sent to the server and the server decrypts the authorization ticket with the server password and obtains the client information directly, including the client access rights. Client information is stored in directory server fields identified by generic field tags. The authorization ticket request identifies client information by tag names identifying the fields, the requested information in stored in the authorization ticket in fields identified by the tag names, and the server mechanism than reads the client information by parsing the ticket with the tag names.

Description

Single Step User ,Authorisation Worth Included User Information Cross References to Related Ap7plications This patent application is related to:
Field of the Invention The present invention relates to a method and apparatus fox 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 Backgrouuad oif 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 sarvices may be provided to the users from bath local servers and from remote servers which axe 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 examplo, the client platforms may use Microsoft Windows and application programs designed to use Microsoft Windows while the server platforms may be based upon the UNIR
operating system. As such, the conzzection 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 problams arise from the inhorent limitat.iozzs of ttze aonnect:ian and communications :~cSC.~.~.~tj.08 as60GiateCl with the c7.ient applications ancl, as a separable problem, with tho inherent, limitations o~' the server programs, suc:lz as the data storage and rotraeval programs executing in the server platGoxms. Thane problems soverely limit tkzo /.......
~~ fl~~

capabilities of the client platforms and server platforms to communicate and to execute data storage and retrieval operations.
Referring first to the c).ient 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 a:lient 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 cliont application may have to wait until a connection is established.
In additian, 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 s9nd and receive moaaagea, and are non-preemptive, so that the current application will complete all message operations before passing the context to another appl:lcation, so that only one application may make use of the connections at a time. 5ti11 further. such applications may be synchronous in that they will sand a message or a request for an operation and than will wait until a response is received before executing a next operation. Therefore, not only axe 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.
Ona solution of the prior art to this problem has been to provide a connection sharing architecture, usually based upon a semaphore mechanism used ixx common by the applications to indicate when a connection is free for use by another applicat.lon. The.: vpproaak~.
however, not only does not solve all a.E the problems of the prior art as deaaxibecl above, but places a further burden on the application programs :1n that each applioatian program must know of the connection sharing mechanism and must operate with the mechanism. Than, for ex ample, requircaa each application to deal with semaphoring and to hold, or dueuo, 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 Lor each new connection . Zn 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 cliont/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 communisation 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 nurnber of .requests that the dispatcher can process in a given time. That is, when the rate at which requests era 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 era submitted to the dispatcher must be limited, for example, by limiting the number of connections supported by the dispatcher or by limiting the rata at which requests may ba submitted through the connections. In additioxx, the cl:~t~iaatch~ar is not avai:l.able to detect new requests while processing a current request, thereby requiring a queue mechanism to hold new requests Cor the c:lispatcl~er. These problems are campounded .in that the reeluest parameters frequently :include addresses, thereby roqu:irix~g 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 systern security, usually by checking the access authorizations of user to various system resources. such as databases and electronic mail services. Fox 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 authenticatioxx 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, clue 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 oJf tie xxwexxtioxx 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 aCCaSS to a server resource .9.xx a server. The r~ystem includes a client mechan:lsm, a server mechanism including a server.
reaourc;e. and an authorization mechanism.
The authorization mechanism includes a directory server for storing access rlghte of a ca.ient and a client mechanism for generating a requecat for an authorization ticket to the server. The request for an authorization ticket i:u<:.iudes an identification of the client and is in association with an operation call to the server.
An authorization mechanism generates a 5 corresponding authorization ticket wherein the authorization ticket includes the ac:Eas rights of the client and is encrypted with an encry~aion key derived from the password of the server and the :<~rlnecti.on mechanism sends the authorization ticket t~::> t:he server me~~hanism ir~ association with the operation cal:l_. The server then decrypts the authorization ticket with the server password and obtains directly the access ri::~t~,ts of the ;:lient to the server resource.
The director~;r server of the authorization mechanism further stor:_:;information regarding the client that required by the s:arwer_ in executing the operation call, including access rights :i..nformation, and the authorization ticket request generated by the client mechanism further includes an identificat:ic:m of the client information required by the server :i.r-i executing t::he operation call. The authorization mechanis_~ is responsive to the ticket request for placing the reques~_e~d info:rmati.orinto the encrypted.
authorization ticket anc~ the server decrypts the authorization ticket anc't reads the information required to execute the operation call directly from the decrypted authorization ticket, '_r~cluding the access rights of the client.
The invention provides an unproved authorization system for use in a dat~~~ processing system, the data processing system including a client which sends operation requests to a server foxy operations to be performed by the 5a server with respect to a server resource within the server.
The authorization syst<:r~~ includes ,:gin <authorization server, a directory server, the .:~emver itsela, and the client itself.
The authorization servfer: is adapter to respond to a request for an authorizat_LOn t i.cket by ret..~rn ing an authorization ticket. The authoriza;~ion ticket contains an identification of the client, access ri.ght:s of the client, and information regarding the client and required by the server when executing the operatioru request:. '),he authorization ticket is encrypted with an encrypt=ion key derived from a server password. The directory server is adapted to store and provide information re~:~arding t=he salient and required by the server in executing thfe operation recuest. Such information includes access rights ca the clie=nt. Suc:h information is stored in fields ident:i_ti.ed by generic field tags. The server itself is adaptE::~d to decrypt the authorization ticket using the server passw~o°d, and is adapted to use the identification of the ~:7_ient in order to obtain the information regarding i::Yoe client and :required by the server when executing the operation request. The client is adapted to generate the reques:_ for tre authcriza:-ion ticket, and to provide the authorizat.:i.orn ticket t~~.~ the server upon receipt of the authorization ti. c:k:et: from the authorization server.
The authorization tickEet: re:~uest generated by the client identifies the client i.roformation by ~.ag names identifying the fields containing :required client information. The requested information i.s stored in the encrypted authorization ticket in fields identi>=:ied by the corresponding tag name.->, and the server reads the client information from the decxrypted a~.zttzorization ticket by parsing the decrypted m:~t.horization ticket with the tag names of the fields corut=wining the necessary client information.

5b The invention also provides an improved method of providing client inform~it:ion t=o a server in a data processing system, the c_:lient generating operation requests for operations to be p~::c:ormed by the server with respect to a server resource. A ~:~:irectox-y server stores client information in fields identified by generic field tags, such information including ac_:~:ess r_ fights of the client to the server resource and information regarding the client required by the server in execution c;f an operation request.
In response to a request from a user for an operation by the server, the client geni~r~~tes a reque~~t for an authorization ticket for the server. 'The request for an authorization ticket includes an idenrificat;ion of the client, and includes the client information in the authorization ticket request by tag names ic:iE~;ntifying the fields containing the required client inform~:xtion. The .client sends the request for an authorization ticket to the authorization server. In response to the request= for an authorization ticket, the authorization server r~~tr_ieves the access rights of the client from the directory server, and generates a corresponding authorization ticket. The authorization ticket includes the accEe:;s rights of the client and the information regarding t=l~ie client required by the server in executing the operation request. ':IhE: authorization server encrypts the authorizat::ion ticket 'with an encryption key derived from the passwo:r~d o:f the server, and stores the requested information iri the encrypted authorization ticket in fields identified bye the corresponding tag names. The authorization server s~~nc:~s the authorization ticket to the client, which sends th~~ authorization ticket to the server along with the operation request. The server decrypts the authorization ticket u,:~:ing the password of the server, parses the decrypted a..~t.lnorization ticket with the tag names ;~ c of the fields containincs the necessary client information to obtain the client info:rrnation, and obtains directly the access rights of the c:l_ient to tpe server resource and the information regarding ?:l-;.e client acid required by the server in executing the operation request.
The invention alsc provides an improved authorization system f::~.~ use i_n a data processing system. A
directory server is ada:~~~t:ed to store access rights of a client to a server resomrce. The client is adapted to generate a request for a.n authorizati.on ticket to the server resource, the request f-c_~r an authorization ticket including an identification of tnE~ client. 'The client is also adapted to send the request fo:r an aut:horizat:ion ticket to an authorization server. U'he authorization server is adapted to respond to the requ~:_,t for an authorization ticket by generating an authoriz_~1=i.on ticket and sending the authorization ticket t::> the client, the authorization ticket including the access rvc~hts of the client and being encrypted with an encr~~~~t:ion k:ey derived from a password. of a server. The client i_:.. responsive to the authorization ticket by sending the ~mt:horization ticket to the server in association with an operation request. The server is adapted to decrypt the a~..zthorization ticket with the password of the server, r:~nd to obtain the identification of the client and the acc~~> rights of the client to the server resource directly from glue aut:horizat.ion ticket.
The invention also provides an improved method of providing client inforrmtion t:o a server in a data processing system. Ac.:ess rights ,:~f the client to a server resource are stored in adirectory server. In response to a user request, the client: generates a request for an 5d authorization ticket to t=he server resource and sends the request for an authcri<~<~~tion ticket t:o an authorization server. Such a request, includes an identification of the client. In response t,:~ the request for an authorization.
ticket, the authorization server retrieves the access rights of the client from the c:lirectory server, generates a corresponding authoriz::~tion ticket, and sends the authorization ticket t::~ t;he client. The authorization ticket includes the ac;E_e>s rights of the ,.~.lient and the identification of the ~_l:ierit, and is encrypted with an encryption key derived from a password of the server. The client sends the author:i zat.ion ticket: to the server in association with the oE:~e x~at:ion request . The server decrypts the authorization ticket using the password of the server, and obtains the identi:Fication of the client and the access rights of the client t::> ~_he sE:rver resource directly from the authorization ticket=.
In another as~~~ect of the present invention, the client information inc:Li:~c~ing the client access rights are stored in the director~;r server in fields identified by generic field tags. The: authorization ticket request generated by the client, mechanism identifies the client information by tag name;: identifying the fields containing the required client inac>rmation and the authorization server stored the requested in?ormati.on in the encrypted authorization ticket in t:ields identified by the corresponding tag names. The server mechanism then reads the client information prom the decrypted authorization 5e ticket by parsing the ~:~f~>.crypted authori~:ation ticket with the tag names of the f:u~:~d containing the necessary client information.
Other feature;>, objE'Cts and advantages of the present invention will. be understood by those of ordinary skill in the art after :eadi.nc~

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 o~ 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 proaent invention;
Figs. 6A, 6B and BC era control data structures used by the servers Fag. 7 is a block diagram o~ an authorization mechanism of the system o~ 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 t4e ConneetROn t4ecb~~anisms (k'ACys. 7l, 2A, ~kl. zC, x.
4A.
~U. ~C. ~~) ~ha following wall d.aSCLISS the OVe.rall structure and operation of the connection mechanism of the present invention and wall then diacusa the basic connection configurations supported by the connection meahaniam. ~'he data structures used by the connection mechanism will than be d:~acusead in further eletail, followed by a discussion o.f 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 tbre Con~aectxo~ ~echanasm Fig. ~) 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) 1~ wherein there are one or more Clients 16 axe residing on CLPT 12 and one or more Servers 18 residing on each SVPT 14 and wherein CLPTs 12 and SVPTs 1~ 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 do:Eined herein as logical communication path between a CLPT 12 and a Server 18 and a session is defined as a logical asaoclation between a Client 12 and a Server 18. As is well understood in the art, Connections 20 may b~ 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 axe used in the present invention for controlling and managing the sharing of Connections 20 among Clients 16.
'.~heae 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 (CODS) 24 for identifying and managing Connections 20, and a set o,f Session Data Structures (SSDSs) 26 relating Clients 16 to Connections 20.
As shown, OLDS 22 includes one or morn Client Control Blocks (CLBa) 28 wherein 4ach CLB 28 contains informata.on regarding a corresponding Client 16 ar Clients 16. CODS 2~ inc:ludes one or more Connpat:ion Control Blocks (CCBs) 30 wherein there is a CCB 30 for and ~~.~? E
_$_ 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 c:orrespaxfdlng sesa3,on and thus with a corresponding Connection 20.
The eliant~ connection and session data structures thereby allow Y
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 aession/connect.ion ralationahip. '.Che Clients 16 are thereby isolated and insulated from the client to connoctian ralationahip 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 moda.ficat.i.op.
'.~'h4 connection mechanism also isolates the connection mechanism .from Cllenta 16~ thercaby allowing the connection mechanism to share fannectiona 20 arnong the Clients 16, 2. Connection Configurations (Figs. 2A. 2~ 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 conziection pooling configuration. The connection mechanism is not, however, limited to these specific configurations and other configurations may be constructed using the general elernents 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 CLH 28, and may thus share the Connection 20 associated with the Session 34.
In the single connection configuration represented in Fig. 2H, there is again a singly Session 34 for each Connection 20 and a single Connection 20 fox each Server 18. While there may be two or moxe 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 morn 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 CLH 28 for each Client 16 and there will be ono or more Soasions 34 for each Client 16. There may, however, be more than one Connection 20 for each Server 18, and moxe than one Session 34 for each Connection 20, so that the Clients 16 share a pool of Connections 20 to ouch Server 18.
B. Detailed DescxipGiox4 of the Connection kxechanisms (Figs. 3. ~A, 4D, !4C. 4D. 4R ~ua~d ~F) The connection mechanism described above will perform several types of opcarations in response to corresponding operation calls from a flient 16. Three of these operations are related to the creation and - 1~ -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 descript.ian 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.
x, dnitialixe and Bind~Unbind O,peratioxas 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 thon issue one or more bind/unbind operation calls to establish and delete connections and sessions with servers and need no,t exaaute the ;initialize call again unless the user application has issued a quit call to romove itself as a Client 1G. As will be desexibed in the subseciuent dHtailed description of the connection mechanism. a Client 16, having eacecutect tho initialize call to become a ~~~~'~~P~

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 fo.r an operation, such as opening a data object or a data read or write, which implicitly requires that the Client :L6 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 mechan3.sm 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 Co~anectxon Configurataon:
The sequence of steps for each operation for the shared connection configuration are:
Inx'ti.alize:
Determines whether a CLB 28 exists and. if not, creates a CLB 28.
As described above. a CL~B 20 :is shared by two or morn Cl:ionts 16 in this connection configuration and a CLB 28 may therefore already exist.
Rs~~.3.c:d~t It,inc~:
Datarmir~es whether a CCB 30 and a SSB 32 exists for the connection and session and creates a CCB 30 and/ar a SSB 32 as necessary if either or both clo not alreac'ly exist.

/Ji -.

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.
acrd increments the implicit bind count for the session.
SuQlicit and Im~la.cit Untried:
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 CL~B 28 will not be deleted when the CCB 30 and SSB 32 a.re 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 Configuxat.i.on:
The sequence of steps for each operation for tho single connection configuration are:
xnitiali~e:
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 errcept that tho connection mechanism determines whether there i.s a ChB 28 already in existence for the individual client and creates a CL,B 28 i.~ a CL~s 28 does not already exist for that client.
Explicit and 7lmlrlicit Hinds:
The steps executed for the explicit and implicit bind operations in tho single connection cozxfiguration are the same as for tho 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.
~xpli.cxt and Implicit lDnbinds:
The steps executed for the explicit and implicit unbind operations in the single connection configuration axe the same as for the shared connection configuration except that, as described, there is a CLB 28 for each client. The CLB 28 .for a client will therefore be deleted vrhen the explicit and implicit bind counts for the last SSB 32 of the client both go to zero or when the client issues a QUIT call.
Connection Pooling Con~Liguration:
The sequence of steps Gor each operation in the connection pooling configuration are:
Initialise:
As in the single connection configuration, there is a CLB 28 for each client and the steps executed in the connection pooling configuration are the same as For the single connection configuration.
Esplicit anal implicit Binds:
As described above, in the connection pooling configuration there is a pool of connections shared among the clients wherein each pool of connections is associatec'l with a given server. The connections in a pool axe therefore associated with a server, and not with a client or clients. Upon a bind call, the aonnect:ion mechanism will determine whether there exists a connc~ct.ion pool associated with the ss;rver designated in the call and, iF such a pool dons not exist, wil:i create a connection pool for the so wer.
A CUnYleGtiQI1 pool is therefore created For a cJi.ven server upon i:he occurrence of the First bind call to the server by any client.
As also described .for the connection pooling configuration. each client has an SSB 32 anfl corresponding Session 3~ for each server ~~.i'~4~

to which it is connected. Therefore, and even if a connection pool to the server was found to already exist, the bind operation will then determine whether an SSB 32 and Session 34 already exists between the client and the designated server and, if not, will make a call to the server to obtain a session identifier and will create an SSB 32.
Explicit and Implicit Unbinds:
The explicit and implicit unbind operatians for the connection pooling configuration will be essentially the same as for the single connection configuration except that. as described. the connections of a connection pool to a server are shared among the clients connected to that server and are therefore associated with the servers rather than with the clients. As such, the CCBs 30 of a connection pool will not be deleted until all the client sessions to the server through the connections o.f the pool have ended, 2. Descript~.on of Connection k~ochanism Data Structures and the Iraecution off Data Operations (Figs. 3. 4A, 4F3, 4C, 4D, 413 and 5~F) As described above, a user application will issue an initialize call to the connection mechanism to become a Client 16 and may then issue one or more bind/unbind operation calls to establish and delete connections and sessions with servers. Raving executed a bind call to establish a connection and session to a server, a Client 16 may than issue one or more calls for server operations.
The following will describe in detail the data structures created and used by the connection mechanism in implementing the above described operations arid for executing server operations and the connection mechanism elements associated with these data structures. The following doecripti,ons axe not based upon any specific canx~ection configuration as the connect:ton configurations and the stops executed by the initialize and bind/unbind operati,on~ for aaah con~~.iguration have been discussed above but, should be read as generally applicable to any connection configuration.

Fig. 3 presents a detailed block of the connection mechanism and includes elements of the connection mechanism not previously shown in Fig.
1. For purposes of clarity in the following detailed discussions, Fig.3 will focus on the individual :functional elements of the connection mechanism. for example, on a single CLB 28, a single CCB 30 or a single SSB
32, and upon the connection mechanism structures and mechanisms associated therewith and with execution of server operations. It will be understood with respect to Fig. 3 that, where a single element is shown and described w.i.th reference to Fig. 3 that also appears in other Figures as a plurality of like elements, the description of such an element will apply to the like elements.
Referring to Fig. 3, the connection mechanism includes a Connection State Machine (CSM) 36 which executes the basic connection/session operations and manages the basic operations for executing server operations across Connections 20. In the present implementation of the connection mechanisms CSM 36 is a commercially available prograrn referred to as Netwise RPC which is available from Netwise Corporation of Boulder, Colorado. CSM 36 performs basic connection and communication operations and the functions,. data structures and operations which use CSM 36 in implementing the connection mechanisms of the present invention comprise the subject matter which is described in detail herein. Thus. CLBs 28, SSBs 32 and CCBs 30 and the related data structures and mechanisms to implement the present connection mechanism are added to the basic mechanism provided by CSM 36.
The control and function mechanisms added to CSM 36 include a Customization Code Mechanism (CCM) as which interacts With CSM 36 to create. manage and use the connection mechanisms of the present invention.
CCM 38 is represented generally in Fig. 3 as CCM 38 and certain functions and routines which are included in CCM 38 will be described together at a later point in the following, Other o~ the olementa of CCM 38 and their ~unat3,ons and operations are ropreaented and discussed individually for a clearer understanding of the structures and operations of the connection meahaniams of the present invention.

~~Q~ ~3 - is -System 10 is represented therein as having at least one User 40 controlling one or more Clients 16 wherein, in the present implementation, each Client 16 is an application program which may generate Operation Calls 42, certain of which establish the application program and User 40 as a Client 16, others of which establish Connections 20 and Sessions 34, and others of which are server operation calls. CLPT 12 may be, for example, a single user personal computer or workstation or may be a mufti-user computer platform. In the first instance there will be one User 40 which may control a plurality of Clients 16 and in the latter instance there may be two or more Users 40. each of which may control a plurality of Clients 16. In still other systems, Clients 16 may not be application programs but may be operating system tasks or other types of programs that make use of Servers 18. In the present example, however, it will be assumed that the system includes at least one User 40 contro7.ling one or more applications programs which operate as Clients 16 by generating operation calls to a So wer 18 through Connections 20.
As will be described in detail ixx a following discussion of System 10's authorization mechanisms, a User 40 will initially log onto System 10 and will be provided with a client identification. Thereafter, whenever a User 40 requests access to a Server 18 the authorization mechanism will check the User 40's authorizations and will return a Client Authorization (CLIENTAUTH) 44. The CLIENTAUTH 44 of a givan User 40 will then be provided to the Server 18 to identify the User 40 and the User 40's access rights to Servers 18. The authorization and protection mechanism of System 10 is the subject of a later detailed description and will be considered only generally for the present description of the connection mechanism.
a. Operation Calls 42 (F:ig. 4A) Thereafter, any Client 16 running under control o:~ a User 4p may generate ona or more Operation Calls 42. The general .format o.C an Opa.ration Call 42 is illustrated in Fig. 4A wherein it is represented that an Qporation Cal7, 42 mt~y include the CGIENTAUTH 44, a Client Identification (CGIENTTD) 46 uniquely identifying the Client 16, a Server Identification (SERVID) 48 identifying the server which is to perform tlxe request. a - m -Function Code 50 identifying the particular operation to be executed on behalf of the Client 16. Each Operation Call 42 will also include a Return Flandle (RETHAN) 52 identifying a Return Handle Area (RETAREA) 54 in CLPT
12's Global Memory (CGMEM) 56 in which the connection mechanism is to place a pointer or address to any data or parameters returned as a result of the request. Finally, each Operation Call 42 will include any Parameters 58 necessary for execution of the Operation Call 42, wherein Parameters 58 may include a Data Pointer 60 to a location in System 10 memory containing any data that is to be send to the Server 18 in executing the Operation Call 42.
b. Client Control Blocs 24 (F'ag. 48) As described, the connection mechanism will create CLBs 24, CCBs 30 and SSBS 32 as required by Operation Calls 42 and the connection configuration in which the connection mechanism is then operating. Client lnitialize/Connection (CIC) 62 will respond to Operation Calls 42 as necessary to create and delete CLBs 24, CCBs 30 and SSBs 32 and the corresponding Connections 20 and Sessions 30 according to the current connection configuration, which is indicated to CIC 62 by Configuration Flags (CONFLAG) 64.
Each CLB 28 is comprised of the CLIENTID 46, an SSB Linked List Address (SSBLA) 62 to the start of a SSL 122, and RETHAN 52. Each CLB 28 therefore includes the information necessary to identify a corresponding Client 16 and to identify the area of CGMEM 56 wherein the Client 16 expects to receive responses from a Client 16 Operation Call. CLDS 22 may contain one or more CLBS 24 and the CLBS 24 are associated through CLL 64 wherein CLL 82 is comprised of one or mor~ CLB Entries 66. Each CLB Entry 66 corresponds to one CLD 24 is comprised of the CLIENTID 66 and a CLB
Pointer (CLBPTR) 68 to the corresponding CLB 24.
c, Co~anectiozt Control Hlocks a0r Request Queues il0 thud Stacks 0!6 ( k'.rl.g$ . 3 r ~f.'r '~Dr 8u0.d ~i'.' ) Referring to F:Lg. 4C, the con:neation mechanism maintains a CCB 30 for each Connection 20 and each CCB 28 in turn contains a Connection Idantitier (CONID) 70 . a Current StaclG Iclcantil=ication (CSTKID) 72, Remote ~~o~~~~
_ lg _ Procedure Call State (RPC STATE) 74, an internal Attribute Count (ATTRCNT) 76, and a Busy flag 78.
Returning to Figs. 3, Figs. 4D and 4E to discuss the functions of CSTKID 72, RPC STATE 74, ATTRCNT 76, and Busy 78, it has been previously described that there is a CCB 30 for each Connection 20. There may be a plurality of Sessions 34 associated with each Connection 20 and each Sossion 34 associated with a Connection may the source of one or more pending Operation Calls 42 that reduire communication with a Server 18 through the Connection 20.
A Connection 20 will execute one Operation Call 42 at a time and will be essentially dedicated to its currently executing Operation Call 42 until completed. As a consequence, any Connection 20 may be executing one Operation Call 42 and may have one or more Operation Calls 42 awaiting execution. As indicated in Fig. 3. therefore, each CCB 30 has associated with it a Request Queue (REQQ) 80 for storing the Operation Call 42 currently being executed through the Connection 20 and any pending Operation Calls 42 that axe to be exocuted through the Connection 20. A
Request Queue Manager (RQM) 82 is provided for managing the REQQs 80.
Each Operation Call 42 that requires communication with a Server 18 will be executed as a sequence of Remote Procedure Call (RPC) requests to the Server 18. Each RPC request is comprised of an RPC call and a corresponding RPC r~sponse and the soquence of RPC requests corresponding to a given Operation Call 42 is stored in a REQQ 80 in tkxe form of a Stark 84 while the parameters associated with the RPC calls and returns are c;ommuninated in packed buffers.
The general structure of a Staclx 84 is illustrated in Fig. 4D. As shown. each Stack 84 includes a Stack Identifier (STKID) 86 wherein the STKID 86 of the Operatian Call 42 currently being executed through the corresponding Connection 20 is stored in the CCB 30 of the Connection 20 as CSTKID 72. Each Steak 108 further includes Session Identifier (SSID) 88, to :Ldentify the Session 22 through which the Reduest 60 is boing executed, and n Pxooess :identifier (PROCID) 90 identifying the Client 16 which was the source of the tOperatian Call 9~2 resulting in the Stack 84. Each Stack 09 wi:l1 also contain RETF1AN 72. thereby idorxtifying the location :1n CGMEM

75 in which the connection mechanism is to place pointers to messages resulting from the connection mechanism operations and, when the Operation Call 42 is completed, a pointer to the results returned from the Operation Call 42.
Each Stack 84 also contains a Sequence 92 of the RPC Requests 94 corresponding to the Operation Call 4?" one of which may be a send request which contains a Buffer Pointer (BUFPTR) 96 to a Buffer 98 containing the p:~rameters of. the Operation Call 42 corresponding to the Stack 84 and the execution of which will result in the Buffer 98 being sent to the server mechanisms.
Referring to Figs. 3 and 4E, CCM 38 will respond to an Operation Call 42 by invoking Packer 100 which will create a corresponding Buffer 98 from the Operation Call 42. The general structure of a Buffer 98 created from an Operation Call 42 is illustrated in Fig. 4E.
As shown in Fig. 4E, a Buffer 98 will contain a Remote Procedure Call Coda (RPCCODE) 102 identifying the operation requested by the Client 16 in the Operation Call 42 and a set of Parameters 104 containing the essential perimeters of the Operation Call 42, including any data that is to be sent to the Server 18.
Returning to Fig. 4C and the structure of a CCB 30. in addition to CSTKID 72, the STKID 86 of the Steak 84 currently being executed. each CCB
30 will also store the state of execution of the currently executing RPC
request of the currently executing Stack 84 as RPC STATE 74. The possible RPC request execution states in the connection mechanism include initialize. pack, sand, receive, and unpack. As will be described with regard to Servers 18. a Server 18 is similarly controlled by the current state of execution of the RPC request and the possible RPC request states that occur in the carver mechanisms include receive, unpack, functzon call, paalc and send.
Of the rpmain~,ng fields of ouch CCB 30, ATTRCNT 76 is used to store repreaenting the number, of attributes (parameters) involved in a current RPC request and is used by the connection mechanisms when unpacking buffers to speed up the unpacking operations by indicating how mush memory wall be required in unpack:lng a buffer. The Busy flag 78 contains a value indicating whether the corresponding Connection 20 is presently executing an Operation Call 42 or has one or more Operation Calls 42 pending fox execution.
Finally, as described, CODS 24 may contain one or more CCBs 30 and the CCBs 30 are associated through CCL Linked List (CCL) 106 comprised of one or more CCL Entries 108. Each CCL Entry 108 corresponds to one CCB 30 is comprised of the CONID 70 and a CCB Pointer (CCBPTR) 110 to the corresponding CCB 30.
d. Session Control Hloc~CS 32 (k'ig. 4F) Referring to Fig. 4F, each SSB 32 includes a Session Identifier (SSID) 112 which identifies the Session 34 to which the SSB 32 belongs. If, as described above, it is necessary for CIC 62 to create a new SSB 32, CIC
62, CCM 38 and CSM 36 will execute a remote procedure call to the Server 18 designated in the Operation Call 42 to a new Session 34 to the Server 18 named in the Operation Call 42. If the Server 18 can support a new Session 34, the server will establish the new Session 34, will generate a uninue SSID 112 for the ~aew Session 34, and will execute a remote procedure response to return the SSID 112 to the connection mechanisms. CIC 62 will then construct the new SSB 32 with the new SSID 112.
Each SSB 38 will also include the Connection Identification (CONID) 70, which is obtained from the corresponding CCB 30 when the Session 34 is established, a Server Text 114, which is a text string Identifying the Server 18 which is involved in the Session 34, and a Server.
Identification (SVRID) 116, which also identifies the Server 18.
Each SSB 32 further includes an Explicit Count Value (Explicit) 118 and an Implicit Count Value (Implicit) 120 which are used to track tha number of Operation Calls 42 currently being executed or awaiting executing in the corresponding Session 34. As described, Operation Calls 42 for a Cannection 20 may be explicit or implicit and the present connection machan~,sm tracks the numbers of explicit and implicit calls separately but, in an t~lternata embodiment. may track both types with a single count. CIC
80 will inorement and dearemant Explicit 1.:1.8 and Tmpliait 120 to indicate the addition of nerr Operation Calla 42 to the Session 32 and the completion of Operation Calls 42 from the Session 32. CIC 80 and CCM 56 track the number of Operation Calls 42 represented in Explicit 122 and Implicit 124 to determine when the corresponding Session 34 has no further outstanding Operation Calls 42 and may be deleted.
Lastly, the SSBs 32 associated with a CLB 28 through a SSB Linked List (SSL) 122 comprised of one or more SSL Entries 124 wherein each SSL
Entry 124 corresponds to a SSB 32 and contains the SSID 114 of the S5B 32 and a SSB Pointer (SSBPTR) 126 to the corresponding SSB 32.
e. CxC 62 Routines Finally, in addition to the above described functions provided by CIC 62, CIC 62 includes a plurality of routines used in the execution of the above described operations o.f the connection mechanisms. Certain of these routines are described below, and the operation of these routines will be well understood by those of skill in the art after study of the above discussion of the operations of the connection mechanisms.
These CCM 38 routines include:
clb Create:
Create the client control block linked list.
Parameters:
Returns: clb root (address of first c1b in c1b linked list) and size of clb.
clb Find:
Find the clb in the c1b linked list Parameters: client identification of client to locate in clb linked list Returns: the pointer (clb ptr) to the appropriate client control block if found in the lanced laqt.
clb ~,aa:
Adcl the client control b:~ock to the linked list.
Parameters: the identification of the client to add to the linked last (claont_ad).
Returns: the idantif:ication of the client added to the linked last (clb_ptr).

- za -clb Free:
Free the client control block from the linked list.
Parameters: pointer to a client control block to be freed (clb_ptr).
Returns: true if done, false if not done.
ssb Create:
Create the session control block linked list if it does not exist.
Parameters: pointer to a client control block for which the ssb linked list is to be created.
Returns: true/false ssb ktame:
Find the ssb in the linked list via server text.
Parameters: pointer to a client control block indicating the client whose ssb is sought (clb_ptr)t pointer to TERT string indicating the name of the server whose ssb is sought.
Returns: a pointer to the ssb (ssb_ptr).
nnb F9.nd:
Find the ssb in the linked list via the server identification (server_id).
Parameters: pointer to a clb indicating the client whose ssb is sought (clb_ptr).
pointer to a WO_SERVER variably indicating the identification of the server whose ssb is sought (sower) .
Returns: pointor to the ssb i:E found (ssb_ptr).
oab Conuaecta,on:
Find the ssb in the linked last via the connection id~ntificatio.n (connection_id).
Parameters: pointer to a clb indicating the client wJ~osa ssb is sought ( c:l.i~_ptr ) .
value of the connection identification to be sought (aonnid).
Returns: a pointer to tho ssb if found (ssb_ptr).

ssbAdd:

Add the ssb to this client's linked list.

Parameters: pointer to a ccb indicating the client for whom the ssb is to be added (c1b_ptr);

pointer to a TEXT string indicating the name of the server (server_text);

pointer to a WO_SERVER variable indicating the identification of the server (server);

the session identification for the ssb (session);

the connection identification for the ssb (connection).

Returns: pointer to the newly added ssb (new_ssb-ptr).

ssbFree:

Remove the ssb from this client's linked list.

Parameters: none Returns: true/false ssbNext:

Returns the next ssb pointer following the input ssb pointer.

Parameters: pointer to the input (current) ssb (ssb-ptr).

Returns: pointer to the next ssb (next_ssb_ptr) Note: to be implemented when multiple servers is implemented.

svbCreate:

Create the svb linked list.

Parameters: none Returns: true/false pointer to start of svb linked list (svb_ptr) size of svb cabCreated Create the ccb linked list :if it does not oxist.

Parameters: none Returns: true/falae pointer to start of ccb linked list (ccb_ptr) slue of CCb.

ccb Find:
Find the ccb in the linked list.
Parameters: the connection identification for whom the ccb is sought (connection).
Returns: pointer to the connection control block (ecb_ptr).
ccb Add:
Add the ccb to the linked list.
Parameters: identification of the connection for whom the ccb is to be added (connection).
Returns: pointer to the newly added ccb (new_ccb_ptr).
ccb k'see:
Remove the ccb from the linked list.
Parameters: pointer to the ccb to be removed (ccb_ptr):
pointer to the head of the ccb linked list (ccb_root).
Returns: true/false.
f. Sum~narx o~ Operation Call. processing According to the connection mechanism described herein, a Client 16 will generate an Operation Call 42 which will be detected by CIC 62. CTC
62 will then find ar create the CLB 24, CCB 30 and SSB 38 as required for the Session 34 and Connection 20 through which the Operation Call 42 is to be executed. CTC 6~ will also invoke Packer 100 which will create a Buffer 98 containing a packed buffer constructed from the Operahian Call 42 and containing the parameters of the Uperation Call 42.
A sequence of RPC requests to execute the Operation Call 42 will constructed as a Stack 84 stored in the REQQ 80 associated with the CCB 30 of the Connection 20. Each Connection 2o will execute one RPC request at a time. and will complete a Stac)c 84 before proceeding to a next Operation Call 42 whose corresponding Stack 84 is stored in its REpp 80.
CIC 62 will return a message to the Client 16 which will offect:lvely complete the Operation Call 42 by Client 16 by indicating aaae~lttlnCQ Of the Operation Call 42. Client 16, which may be either a synchronous ar asynchronous procoas, may thereby resume operation and either generate further Operation Calls 42 or by passing the operating ~10~~~~

system context to another Client 16.
Each RPC request call/return operation executed from a Stack 84 will be "stamped" will the session identifier and at least certain of the call/return operations will contain the client identifier. The server mechanism, described in following discussions, will execute each of the RPC
requests operations sent by the connection mechanisms and will return the results of the operations to the connection mechanisms through the Connection 20 through which th~ server mechanisms received the call/return operations. The responses returned to the connection mechanism from the server mechanisms will be "stamped" with the session identifier.
The final result of the RPC .requests corresponding to an Operation Call 42 is sent to the connection mechanism from the server mechanism as a packed Buffer 100 associated with a server generated remote procedure call wherein the parameters contained in the packed Buffer 100 will include the results generated in response to the Operation Call 42.
CCM 38 and CSM 36 will receive the Buffer 100 returned from the server and will invoke Unpacker 128 which will unpack the Suffer 100 returned from the server into a Return Area 130 of CGMEM 76. Unpacker 128 will place a pointer to Return Area 130 into Return Handle Area (RETAREA) 54 and will provide a message to Client 16 that the results of the Operation Call 42 have been returned.
Each server response to an RPC request from the connection mechanism is "stamped" with the session identifier, so that the SSB 32 is knoorn. As described. each Connection 2U executes one Steak 84 at a time and all server responses to RPC reduests from the connection mechanism are sent to the connection mechanism through the Connection 20 through which the RPC
request was sent to the server, so that the Connection 20 and CCB 30 are known. The Steak 84 is therefore lcnown and contains a process identifier, so that the Cl:lent 16 can therefore be :identified, SSBs 32 therefore relate the Clients 16 as identified through the C!'Jklr~ 24 with the Connections 20 as identi,Cied through the CCRs 30, by :t,dentifying a corresponding Session 34, that is, a logical association through the Connection 20 between the Client 16 and a server. SSBs 32 further provide a means for associatincr each request o.f a Client 16 operation call with a corresponding Session 34, and thus with a corresponding Connection 20, by providing a means for stamping, or identifying, each request with the session identification.
The connection mechanism described above thereby provides separate and independent mechanisms for managing clients and connections.
respectively the client control blocks and the connection control blocks, and provides a third mechanism, the session control blocks, for relating clients and connections. The client, connection and session data structures thereby allow a Client 16 to operate in terms o~ operation calls to server urhile system relates each operation call to a session and a connection identified through the corresponding SSBs 32 and the CCBs 30, thereby converting each client/operation relationship into a session/connection relationship. The Clients 16 are thereby isolated and insulated from the connection/server relationship and need not deal with the complexities of the connection/server relationship. thereby reducing the burden on the Clients 16 and all4wing the Client 16 normal internal request mechanisms to operate without modification. The connections and servers are likewise :isolated from the clients.
The connection mechanism described herein thereby allows flexibility in arranging connection configurations and, in particular, the construction of shared and pooled connection configurations and the user of the system can readily select the particular configuration to be used by setting the appropriate flags of CQNELAG 64.
Tn this regard. it should be noted that the m are certain tradeoffs between the various connection configurations, for example. the sha>"ed connection configuration requires only ono connection regardless of the number of application progfams running on a client platform, thereby conserving connections, and does not require the creation of a new connections or sessions with each new cliexat, thereby decreasing the Mart-up time .far each client. The single connection configuratian, however,, offers the best throughput rate for a given client axed connection aaut is most expaxasive in resources and requires increased start-up time for each new client as a new connection and session must be started for eacYa xaow client. The pooled connection configuration, in turn, does not require _ Z7 _ the creation of a new connection for each operation, if the connection pool already exists, but does require the creation of new sessions.
In addition, and as will also be described in detail in the following, the Client 16 request mechanisms may be synchronous or asynchronous, without restriction, because the connection mechanism interface with the Clients 16 operates synchronously with .respect to Clients 16, thereby satisfying the interface requirements for both synchronous and asynchronous Clionts 16. That is, a Client 16 will issue a call for an operation to be performed with respect to a server and the connection mechanism will respond by providing and acceptance of the call to the Client 16, thereby completing the call operation by the Client 16.
In the instance of a non-preemtive, pseudo-multitasking Client 16, for example, such as Microsoft Windows and Windows applications programs, a Client 16 is thereby freed to generate further Operation Calls 42 or to pass the operating system context to another application program upon the connection mechanism's reaponso that an Operation Call 42 has been accepted. The connection mechanism will provide the rosults of the Client 16 call to the Client 16 in a subsequent and separate and operation. The operation of a client system is therefore not held up while waiting a response to a given Operation Call ~2, thereby significantly increasing the efficiency of operation of the clients system.
The connection mechanism, however. operates asynchronously with respect to the assignment of connections and the execution of requests through the connections, thereby significantly increasing the efficiency of use of the connections.
Finally. 3,n the present implementation of System 10, CLPT 14 is a single usar personal computer or workstation and Clients 12 are Microsoft Windows applications running in the Microsoft Windows environment under control of users. 7,'hca Server 16 mechanisms of the present. :Lmplomentation arc IJN:fX processes running on the UN7LX operating system a.nd 1>roviding database services. In other implementations, CLPT :l~ may be a mufti-user computer platform and Clients 12 may not be application programs but may be operatinn system tasks ox other types of programs and Server 16 may not be a fiatabaae aervar~ but may ba any other fortn of server, such an electronic mail aervar or a painter server.

C. Detazled Descriptions o~ Server Meclhanisms (Figs. 1,. 5, 6A, 6D, 6C, 6D
and 6E) 1. General pescription (Fig_ 1) Referring again Fig. 1 and the Servers 18 of SVPT 14, the RPC
requests generated by the connection mechanism as a consequence of Operation Calls 42 for Server 18 operations with respect to a Server Resource 132 are received by a Dispatcher 134 through one or more Connections 20 and Dispatcher 134 in turn communicate the requests to one or more Worker Tasks 136 through corresponding ones of Dispatch/Worker Shared Memory Area (DSMAs) 138. Worker Tasks 136 in turn perform the Client 16 operations with respect to Server Resource 132 and return the results of the operations to Dispatcher 134 through DSMAs 138.
The sequence of operations required for performing an RPC request communicated to Server 18 from the connection mechanism is comprised of a sequence of operations. certain of which are concerned with the reception of requests through Connections 20 and the sending of responses back through Connections 20 and others of which are concerned with the actual operations with respect to Server Resource 132. These operations are divided between the Dispatcher 134 and the Worker '.Casks 136 so that the operations for receiving requests, assigning requests to Workex Tasks 136 and sending responses resulting from Worker Task 136 operations back through Connections 20 to the connection mechanism are executed by Dispatcher 42. The operations pertaining to Server Resource 132 are.
correspondingly, performed solely by Worker Tasks 136. including the checking of user authorisations and the interpretation and execution of the RPC requests as Server Resource 132 operations.
In this regard. it has been described that each RPC request received from the connection mechanism by Dispatcher 134 is comprised of a remote procedure call and an associated packed Hu.~fer 98 which contains the parameters of the request. Dispatcher 134 receives each such t3uffer 98 dirertlx into the I)SMA 138 associated with the Worker 7.'ask :136 which has been assigned to handle the RPC request and notifies the assigned Worker ',Casks :136 that it has a task to perform by setting a semaphore associated with the Worker Task 136. The assigned Worker Task 7.36 will unpack the _ 29 -Buffer 98 and perform the operation with respect to Server Resource 132 specified by the RPC request. It should be noted that the Worker Task 136 will unpack the buffer from its DSMA 138 and into its own memory space, so that no address translation operation is required.
The Worker Task 136 will, upon completing the specified operation vrith respect to Server Resource 132, pack the results of the operation directly .into a buffer in its USMA 138 and vrill issue a remote procedure call to Dispatcher 134, indicating that the operation is completed.
Dispatcher 134 will then send the results buffer directly from the DSMA 138 to the connection rnechanism, thus completing the RPC request from the connection mechanism.
As shown, there is a Dispatch State Machine (DSM) 140 associated with Dispatcher 139 to control the operations o~ Dispatcher 134 and an instance of a Worker State Machine (WSM) 142 associated with each Worker Task 136 to control the operations of the associated Worker Tasks 136.
finally, Worker Tasks 136 sham a Worker Shared Memory Area (WSMA) 144 through which Worker Tasks 136 communicate and coordinate their operations with respect to Server Resource 132.
2. Detailed DescriQtion o~ a Server 1t3 (P'zgs. 5.. 6A and 6k3) Referring to Fig, 5, therein is shown a detailed block diagram of a Server 18 running on SV'PT 14, certain elements of which have been previously described with reference to Fig, 1. Fig. 5 shows a single instance of a Worker Task 136 and the structures and mechanisms associated with a Worker Tasl~ 136 but It will be understood that the Sever 18 may include a pluralitx of Worker Tasks 136 and associated structures and mechanisms.
As indicated therein Dispatcher 134 maintains several data structures for controlling operations o:E Workers 136 and for coordinating the execution of the RPC requests and associated buffers through Connaatioxxs 20. Fox example, associated with DSM 140 :is a Dispatcher Statc structure (DSTATE) 146 comprised o:( an array of Dispatcher State Entries (DSTATE ENTRIES) 148 wherein ouch DSTATE ENTRY 148 corresponds to an RPC
roc~uoat being executed through a Session 34. Each DSTATE ENTRY 148 is :indexed bx the corresponding Worker Task :identifier (WID) 150 identifying a corresponding Worker Task 136 assigned to the RPC request and contains the current State of Execution (STATEX) 152 of the corresponding request.
Dispatcher 134 also maintains a Session Control Structure (SCS) 154 comprised of an array of SCS Entries 156, each of which corresponds to a Session 20 through which a Client 16 operation is being performed and contains a Session Control Block (SCB) 158 which is indexed by the corresponding SSID 112 and contains information used by Dis,pataher 134 in controlling execution of the corresponding Session 20. As indicated in Fig.
6A, each SCB 158 contains the Session Identifier (SSID) 112, the Client Identifier (CLIENTID) 46, and a Dispatcher State Pointer (DSTPTR) 160 to the corresponding Dispatcher State Entry 1148 in DSTATE 146. Each SCB 154 also contains Client Privileges field (C.LTPVG) 162 containing the access and authorization rights of the User 40.
Finally, Dispatcher 42 maintains a Worker Control Structure (WCS) 164 comprised of an array of plurality of WCS Entries 166, each of which corresponds to a Worker Task 136 and contains a Worker Control Block (WCB) 160 which is indexed by the corresponding WID 150 and contains information relating to control of the Worker Tas)s 136. As indicated in Fig. 68, each WCB 168 contains the Worker Identification (WID) 150 and a Dispatcher Shared Memory Area Control Block (DSMACB) 170 which in turn contains a Dispatcher Shared Memory Area Address (DSMAA) 172 gointing to the location of the DSMA 46 shared by Dispatcher 42 and the particular Worker Task 136 and a Dispatcher Shared Memory Aroa Size (DSMASZ) 174 value indicating the size, or capacity, of the DSMA 138 shared by Dispatcher 134 and the particular Worker Task 136.
Each WC8 166 further includes the Connection Identification (CONID) 70 of the Connection 20 through which the corresponding request is boing executed and the Session Identifier (SSID) 112 of the Session 20 through which the request is being executod. Each WCB 168 also includes SCB
Session Control Block Pointer (SCBPTR) 176 to the SCD 158 corresponding to the RPC request currently being handled by the corresponding Worker Task :136 and a Dispatcher Remote Procedure (;all State Pointer (DRPCSTPTR) 178 to the corresponding STATEX 152.
Each WCB 168 also includes a Worker State field (WSTATE) 180 containing Flags regarding the current state of the corresponding Worker Task 136, such as whether the Worker Task 136 is idle, busy, in initialization, or being terminated and a Semaphore field (Semaphore) 182 which is set by Dispatcher 134 to init3.ate the Worker Task 136 operation to handle a new RPC request received from the connection mechanism. Finally, each WCB 168 contains a copy of CLIENTAUTH 42 which is received from the appropriate SCB 158 when the Worker Task 136 is assigned a new RPC request.
Referring again to Fig. 5, therein are illustrated the remote procedure calls and packed buffers exchanged between Dispatcher 134 and a Worker Task 136 through the DSMA 46 associated with the Worker Task 136. As indicated, Dispatcher 7.34 will receive an RPC request from the connection mechanism and will select a Worker Task 136. The packed Buffer 98 associated with the RPC request will be written directly into the DSMA 138 of the selected Worker Task 136 and Dispatcher 134 will set the Semaphore 182 of the corresponding WCB 166.
The selected Worker Task 136 will respond to the Semaphore 187., vrill invoke an UNPACK 186 function to unpack the Buffer 298. and will execute the Server Resource 132 operation specified by the RPC request.
Upon completion of the operation, the Worker Task 136 will invoke a Pack function 188 to directly pack the results of the operation into a Buffer 200 in the DSMA 138. Again, no address translation is required when packing the results of the operation into Buffer 200 as DSMA 138 is within the memory space ok the Worker Task 136.
The Worker Task 136 will then issue a remote procedure call (RPC) 200 to Dispatcher 7,34 through a Worker Connection WCON) 204 to indicate that the request has been completed. WCON 204 is created by Dispatcher 134 Per the passing of remote procedure calls from a Worker Task 136 to Dispatcher 134 and each such WCON 204 connection is assigned a unique Worker Connection Tdent:ifior (WCOD1ID) :L06 wherein the WCUNID 20G .Eor each Worker Task 136 i.s stored in the carresponding WCB 168.
Dispatcher :L34 send the results Buffer 200 cl:treatly .from the DSMA
L38 to ,the cormeat~,on mechanism, thereby completing the RPC request.
Tn th.Ls raspsat~ it should be noted that all communications to Dispatcher 134, whether from the connection mechanism or from a Worker Task 136, are in the form of a remote procedure call communicated through a connection with an associated packed buffer containing the parameters of the call. This both simplifies the design of Dispatcher 134 and insures that a Worker 'Task 136 cannot preemptively interrupt the operations of Dispatcher 134. For example. it is preferable that Dispatcher 134 delay responding to a remote procedure call .from a Worker Task 136 in order to receive and handle another remote procedure call through a Connection 20 from a CLPT 12.
Finally it will be noted that each Worker Task 136 has access to WSMA 144 wherein information regarding the data objects to which the Clients 16 have requested access is stored and that, as described this information is used to coordinate access to the data objects by Worker Tasks 136. WSMA 144 is provided for this purpose because, as described the same Worker 7,'ask :136 will not necessary perform all Client 16 operations with respect to a given data object and this information is therefore stored in a central location accessible to all Workers Tasks 136 rather than in the individual Worker Tasks 136.
WSMA 144 is used to store one or more Open Object Control Blocks (OOCBs) 208 wherein each OOCB 208 corresponds to a single data object to which a Client 16 and User 40 has requested access. As shown in E'ig. 6C.
each OOCB 208 contains an Object Identifier (OBJID) 210 of the corresponding data object, the CLTENTID 46 of the User 40 which has requested and received authorization to access the data object, the CLTPVG
162 containing the privileges of that User 40. and a set of Locks 212 which are set and reset by the Worker Tasks 136 when accessing the data objects to prevent access conflicts between the Workers 136.
3. s,~arx To summarize, in the system of the present invention client operation calls are each broken down into a sequence of remote procedure resluests by the connection mechanisms. Each remote procedu.r.e c~tl1 request :ls then,inctividually communicated to the server mechanism as a remote procedure call and pacJced buffer and the dispatcher running on the server platform dispatches each remote procedure call to a selected one of a plurality worker tasks for execution by placing the packed buffer directly into a shared memory area associated with the assigned worker task and setting a semaphore associated with the worker task. The selected worker task will execute the request and will return the result to the dispatcher through a remote procedure call to the dispatcher and a pacJced buffer written into the worker's shared memory area. The dispatcher will then send packed result to the connection mechanism directly from the shared memory area.
It can be seen, therefore, that while each connection can support only one remote procedure call at a time, the time required to execute each such remote procedure call is relatively brief compared to the time required to execute an entire client operation in its entirety and that a connection can interleave the remote procedure calls of a plurality of client operations.
It can else be seen from the above that because the dispatcher is required to perform only certain tasks, such as receiving remote procedure call requests, assigning remote procedure call requests to worker tasks, and sending responses from worker tasks back to the client platforms. the burl~n of operations on the dispatcher is significantly reduced and the rate at which the dispatcher can process requests is significantly Increased. In addition, and because the dispatcher passes each remote procedure request to a worker task and saves its state with respect to each remote procedure request passed to a worker task. the dispatcher is free to concurrently process a plurality of remote procedure requests. thereby significantly increasing the number of requests and thereby the number of connections and sessions that the server can handle at any time.
It has been described that Dispatcher 7.5~k communicates with each Woxkex '.Cask :136 tYxrough DSMAs 130 associated with the individual Worker Tasks 136. With regard to the communication of requests from Dispatcher 131 to a Worker Task 136, the packed buffer associated with a xequeat l:rom the cOnneCtion mechanism is received directly into the DSMA 130 and is unp~u:ked from the DAMS 130 by the assigned WoxJcex Task 136. This reduces the number of xocluixed operations by bath Dispatcher 131 and the Worker Tasks :136 in th~~t the packed bufJ:era need not be moved from a Diapatc.her 134 memory spaap to a Worker Ta&k 136 memory space and further eliminates the need for _ 34 _ address translation operations by either Dispatcher 134 or the Worker Task 136 because the buffer is unpacked within the Worker Task 136 memory space.
In addition, the use of a semaphore to notify the Worker Task 136 that it has a task to perform further reduces the time required for Dispatcher 134 to handle an RPC request as Dispatcher 134 need not wait for an acceptance from the Worker Task 136. Instead, Dispatcher 134 simply sets the semaphore and proceeds to its next operation.
As regards the communication of results from a Worker Task 136 to Dispatcher 134 and back to the connection mechanism, all communications to Dispatcher 134, whether from the connection mechanism or from a Worker Task 136, are in the form of a remote procedure call communicated through a connection with an associated packed buffer containing the parameters of the call. This both simplifies the design of Dispatcher 134 and insures that a Worker Task 136 cannot preemptively interrupt the operations of Dispatcher 134. For example, it is preferable that Dispatcher 134 delay responding to a remote procedure call from a Worker Task 136 in order to roceive and handle another remote procedure call through a Connection 20 from a CGPT 12. In addition, and again, this reduces the number of required operations by both Dispatcher 134 and the Worker Tasks 136 in that the packed buffers need not be moved from a Worker Task 136 memory space to a Dispatcher 134 memory space and further eliminates the need for address translation operations by either Dispatcher 134 or the Worker Task 7,36 because the buffer is unpacked and packed within the Worker Task 136 memory space Finally, it should be noted that a given system is not required to implement both the connection mechanism running on the client platforms and the sorver mechanism running on the server platfarm. That is. the connection mechanism and the server mechanism are implementeel to communicate through remote procedure calls with aSBQCiated packed buffers containing the parameters of the calls. Thus, tkzo connection mechanism may be implemented with any server mechanism using remote procedure calls and the server mechanism may be .implemented with any client connection mechanism using remote procedure calls. In each instance, the advantages cler:l.ving Exam the use of the portion of the present system that is implementeel in another system will be realized.

_ 3g _ D. Detailed Descra.ption o~ the Authorization Diechanis~ (Figs. 3~ 5 and 7) As briefly described above, a User 40 will initially log onto System 10 and will be provided with a client identification. Thereafter, whenever a User 40 requests access to a Server 18 the authorization mechanism will check the User 40's authorizations and will return a Client Authorization (CLIENTAUTH) 44. The CLTENTAUTH 44 of a given User 40 will then be provided to the Server 18 to identify the User 40 and the User 40's access rights to Servers 18. System 10's authorization mechanism is cfenerally represented in Fig. 3 as Authorization Mechanism (RUTH) 214 and is described in further detail below.
Referring to Fig. 7, therein is shown a diagrammatic representation of RUTH 214 of the present system. RUTH 214 is a modified vorsion of the Kerberos authentication system developed by and available from the Massachusetts Institute of Technology in Cambridge, Massachusetts.
As shown in Fig. 7. RUTH 214 includes an Authorization Server 216 and a Directory Server 218. Directory Server 218 stores User 40 log-in names, User 40 passwords, Usor 40 access rights to the various Server 18 resources, such as databases, and a password for each Server 18.
A User 40 will log-in to System 10 by entering their Log-in Name (LTN) 220 to Log-Tn/Authenticator (LTA) 222 running in CLPT 12. LIA 222 sends Log-in Name 220 to Authorization Server 216. Authorization Server 216 responds by checking LIN 220 in Directory Server 220 and obtaining two encryption keys. respectively indicated in Fig. 7 as User Password Encryption Key (UPEK) 226, which is derived from the Llser 40 password. and Ticket Encryption Key (TEK) 228, which is derived from the Authorization Server 218 password.
Authorization Server 216 then generates a Sealed Authorization Server Ticket (SAST) 230 which contains authorization for the Usor 40 to access Authorization Server 216. As indicated in Fig. 8A, a SAST 230 will .include at least LIN 22?, and a Ticket Session Kay (TSSK) 232 and is pnarypt~acl by Authorization Server 2.18 with 7.'EK 220. Authorization Server 2:1.6 then generates a Message 234 which includes TSSK 232 and a S.AST 230 and onerypte Mossage 234 witkx the UPEIC 226.
Message 234 is then returned to User 40 and User 40 is prompted for the User 40 Password 236. The User Password 236 entered by User 40 is encrypted by LIA 222 to generate a User Password Encryption Key (UPEK) 226 which is used to decrypt Message 234. If the UPEIC 226 which is generated from User Password 236 as provided by User 40 is the same as the UPEK 226 obtained by Authorization Server 216 from Directory Server 2:L8, then Messago 234 will by decrypted to obtain TSSK 232 and SAST 230, wherein BAST
230 is still encrypted by TEK 228. TSSK 232 and SAST 230 will be stored in CLPT 12.
Thereafter, when User 40 wishes to request an operation with respect to a Server 18, User 40 will identify the Server 18 to LTA 220 which will generate a Ticket Request Message (TRM) 238 as represented in Fig. 8B. TRM 238 includes a Server Name (SVRN) 240 of the Server 18. SAST 230, and a Sealed Authenticator (SA) 242, which in turn includes at least LTN 220, wherein LIA 222 will encrypt SA 242 with TSSK 232.
LIA 222 then sends TRM 238 to Authorization Server 216, which will decrypt SA 242 using TSSK 23?. and will decrypt SAST 230 us:Lng TEK 228.
Authorization Server 216 will then check LIN 220 and, if correct. will index Directory Server 220 with SVRN 240 to obtain a Server 18 Encryption Key (SEK) 244 for that Server 18 wherein SEK 244 is the password for the Server 18. Authorization Server 216 will also index Directory Server 218 with LIN 220 to obtain the client access privileges (CLTPVG 162) to that Server 18 for that User 40.
Authorization Server 2:L6 will encrypt CLTPVG 162 using SEK 244 as the encryption key to generate a sealed Server 18 authorization ticket, which is rofrarred to herein as CLIENTAUTFI 44. Authorization Server 2:L6 will thon construct an Authorization Messago (AUTHMSG) 246 which :includes C~IN
220 and CLTENTAUTH 44, will encrypt AUTFIMSG 246 wath UPEK 226, and will return AUTHMSG 246 to LIA 222.
LIA 222 w:lll decrypt AU7.'HMSG 246 using UPEK 226 to obtain CL~:ICiNTAUTFI 44. which wall still b~ encrypted with SEK 244 and CLIR'NTAUTH

w:lll ba sent to Server 18 as described above with regard to the operation of thp connect:lon moahanism and Server 18. The assigned Worker Task 136 of tha aorver :18, which knows a.t own password, that as, SEK 244, will decrypt CLIENTAUTFI 44 to obtain CLTPVG 162.
Rather than placing just a log-in name or identi:Eication number in CLIENTAUTH 44, therefore, Authorization Server 216 will place more information about the user, such as the user's access rights and display name, which is information that the Server 18 would typically have to reduest from Directory Server 220. By having this information in the authentication data, Server 18 has no need to contact Directory Server 220, thereby saving time in checking the user access rights and eliminating the need to trust the Server 18 with access to Directory Server 22D.
Note that the Client 16 cannot access or modify this additional information because the additional information is stored in CLTPVG 162 which is encrypted with the Server 18's password. The Client 16 thereby receives the encrypted CLIENTAUTH 44 from Authorization Server 216 and passes it to the Server 18, but only the Server 18 has the correct password necessary to decrypt the information. For this reason, Server 18 can trust the user information without having to go to the security database in Directory Server 2~0 itself.
The information included in CLIENTAUTH 44 may include access rights. display name, administrator flag. and so forth. The information needed by oach typo of Server 18 may be different. For example, a printer server ne~ds to know if the user can access the printer that the user wants to print on, while a database server needs different access rights information. To keep the architecture efficient and flexiblo, the Client 16 tells Authorization Server 216 which information and access rights it wants retrieved from Directory Server 220 and stored in the encrypted ticket.
Aa an examplo, a usor may want to print on LASER12 using the aervar name printaerver. The client printing application will make a ronuest to Authorization Server 2:1G for a CLIENTAUTH 44 which will allow it to talk to the server "printserver". In addition, the client will aslc Author:lzation Server 216 to retrieve t:he access rights that the User <E0 has for using printe.ra. Authorization Server 216 w:il.l rotriove the printer acaoea r:lghts fox the apeaified User 40, and will put them in the security packet, that is, in CLTPVG 162. Th:ls packet is then encrypted in the pr,l,ntaerver'a password, and the resulting CLIENTAUTFI 44 sent back to the client. The client passes the CLIENTAUTH 44 on to pri.ntserver along with the file to be printed. The printerserver server will decrypt the CLIENTAUTH 44 to obtain the CLTPVG 162 and check that the printing access rights contained therein allow the user to use LASER12.
Tt should also be noted that the authorization mechanism described herein provides a means fox providing all forms of information about a user to a server, and is not limited to only access rights.
In order to keep the authorization protocol, Authorization Server 216 and security databases in Directory Server 218 :Flexible, the protocol and database may define a format using generic field tags, which may be either be numeric or character strings. These tags allow a client to request information by using tag names, and for Authorization Server 216 to retrieve the information using tag names. This prevents Authorization Server 216 from having to specifically code for certain types of information for certain servers. The Sorver 18 can also pull information out of. the CLTPVG 16Z using the same tag names.
A recjuest to Authorization Server 216 would thereby have the following format:
[username][appservername][tagA][tagH]
where username is the name of the User 40 the information is being requested for, appservername is the name of the server the CLTENTAU'.PH
44 is being generated for, and tagA and tagB are the tag names of the information desired; for eacample, tagA and tagB could be "PRTNTER-RTGEITS" and "ADMTN_RTGFfPS".
Authorization Server 216 would then make a generic query against the security database in Directory Server 218, retrieving the fieldF with the specified tag names for the specified user wheroin the information an the clatabase is tagged with tkxe different tag .names, allowa.ng generic c,(t,terien. Authorization Server 2:i6 woi.Vd then pack the fields .into a secGtxlty packet CL~TPVG 162 and encrypt CLTPVG 162 with tkxe ai>pservername's password to obtain the correspoxxding CLTEN'tAUTFk 44, and send CLTENTAUTtk 44 bask to the client.

CLIENTAUTH 44 would then have the following, all of which would be encrypted with the servers password:
[username](appservername][tagA][lenA][dataA][tagB][lenB]
[dataB]
where tagA is the tag name of the piece of information requested, lenA is the length of the information returned, and dataA is the actual data.
The Server 18 would receive CLIENTAUTF1 44 from the client, decrypt it to obtain CLTPVG 162. and then parso CLTPVG 162 to pull out the information it needs. The actual format of the data, that is, whether it is a character string. numbers, structure, and so on, is specific to the server.
It is apparent from the above description of the authorization mechanism of System 10 that the authorization mechanism decreases the operational load on the server mechanism and is able to provide a significantly enhanced response time in authenticating clients wishing aaeess to the resources of a server. The server need not perform a separate operation to access the authorization mechanism and system directory server to obtain the access rights and ether information of a user. Instead, the access rights and any other information are provided directly to the server together with the request for a sereor operation.
In addition, there is no compromise of secur3.ty in providing the access rights directly to the server from the client as the access rights are obtained from the authorization server and, before being sent to the client, axe encrypted with the servor password which is known only to the authorization mechanism and the server. Thus system security is at toast oqual to that provided by the authorization mechanisms of the prior art.
The authorization mechanism described herein also reduces tho operational load on the di.reatory carver by eliminating directory server noaasse9 by Servers l8. In9tead, wkxat would have been done by a separate ac;cese to the directory sereor by a Server 18 is performed when the User 4Q acaasses Authorizat.ian Servor 216 and Directory Sorver 2:(.8 to obtain amthor3,zation to access the Server :LB, so that two separate operations are replaced by one operation.
In addition, system security is enhanced in that only the authorization server needs to access the directory server to obtain information about users and it is no longer necessary to enable Servers 18 to access the directory server, or to trust Servers 18 with access to the directory server. This in turn eliminates a possible security breach wherein a false Servor 18 or other server or application must be allowed to across the directory server to obtain information about any user.
Finally, it should be noted that the authorisation mechanism described herein is not limited to providing only access rights information to Servers 18, but may provide any information regarding the user or client application that a Server 18 may require and which would otherwise be obtained by a separate access of Directory Server 220 by a Server 18, such as a user display name or administrative information.
In this regard, the format and protocal through which information is retr.iaved from Directory Server 218 by a client and retrieved from a 4L~TPVG 162 by the sarver is .flexible so that any desired information may be retrieved and provided to the server using the same protocol and format. As described, this flexibility is obtained through the use generic field. tags and tag names to identify and retrieve the information, thereby avoiding the limitation o~ specific encoding for each specific type of information.
While the invention has been particularly shown and described with reference to preferred embodiments of the apparatus and methods thereof, it will be also undHrstood by those of ordinary skill in the art that various changes, vaxiatinns and mod~.fications in form, details and :Lmplementation may be made therein without departing from the spirit and scope of the invent9.on as defined by the appended claims. Therefore, it is the object of the appended claims to cover all such variak.:ton and modifications of the invention as come within the true spirit and scope oC the invention.

Claims (6)

1. In a data processing system including a client which sends to a server operation requests for operations to be performed by the server with respect to a server resource within the server, an improved authorization system comprising:
an authorization server adapted to respond to a request for an authorization ticket by returning an authorization ticket containing an identification of the client, access rights of the client, and information regarding the client and required by the server in executing the operation request, the authorization ticket being encrypted with an encryption key derived from a server password;
a directory server adapted to store and provide information regarding the client and required by the server in executing the operation request, including access rights of the client, the information regarding the client being stored in fields identified by generic field tags;
the server adapted to decrypt the authorization ticket with the server password and adapted to use the identification of the client to obtain the client access rights of the client to the server resource and to obtain the information regarding the client and required by the server in executing the operation request;
the client adapted to generate the request to the authorization server for the authorization ticket to the server, and adapted to provide the authorization ticket to the server in response to receipt of the authorization ticket from the authorization server;

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 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 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, a server including a server resource, an authorization server, and a directory server, the client generating operation requests for operations to be performed by the server with respect to the server resource, an improved method of providing client information to the server comprising the steps of:
storing client information, including access rights of the client to the server resource and information regarding the client required by the server in executing an operation request, in the directory server in fields identified by generic field tags;
in the client and in response to a request from a user for an operation by the server, generating a request for an authorization ticket to the server, the request for an authorization ticket including an identification of the client and including the client information in the authorization ticket request by tag names identifying the fields containing the required client information;

in the client, sending the request for an authorization ticket to the authorization server;
in the authorization server and in response to the request for an authorization ticket, retrieving the access rights of the client from the directory server, and generating a corresponding authorization ticket wherein the authorization ticket includes the access rights of the client and the information regarding the client required by the server in executing the operation request, encrypting the authorization ticket with an encryption key derived from the password of the server, and storing the requested information in the encrypted authorization ticket in fields identified by the corresponding tag names;
in the authorization server, sending the authorization ticket to the client;
by operation of the client, sending the authorization ticket to the server in association with the operation request;
and in the server, decrypting the authorization ticket with the password of the server, 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 to the server resource and the information regarding the client and required by the server in executing the operation request.

3. In a data processing system including a client, a server including a server resource, and an authorization server, the client generating operation requests for operations to be performed by the server with respect to the server resource, wherein the client mechanism providing the authorization ticket to the server mechanism associated with an operation request, the server mechanism decrypting the authorization ticket with the server password, an improved authorization system comprising:
a directory server for storing access rights of the client to the server resource;
the client adapted to generate a request for an authorization ticket to the server resource, the request for an authorization ticket including an identification of the client, and to send the request for an authorization ticket to the authorization server;
the authorization server adapted to respond to the request for an authorization ticket by generating a corresponding authorization ticket and sending the authorization ticket to the client, wherein the authorization ticket further includes the access rights of the client and is encrypted with an encryption key derived from a password of the server;
the client being responsive to the authorization ticket by sending the authorization ticket to the server in association with the operation request; and the server adapted to decrypt the authorization ticket with the password of the server and to obtain the identification of the client and the access rights of the client to the server resource directly from the authorization ticket.

4. The improved authorization system of claim 3 wherein:

the directory server further stores information regarding the client and required by the server in executing the operation request;
the authorization ticket request generated by the client further includes an identification of the client information required by the server in executing the operation request;
the authorization server is responsive to the authorization ticket request by placing the requested information into the encrypted authorization ticket; and the server 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, a server including a server resource, an authorization server, and a directory server, the client generating operation requests for operations to be performed by the server with respect to the server resource, an improved method of providing client information to the server comprising the steps of:
storing access rights of the client to the server resource in the directory server;
by operation of the client and in response to a user request, generating a request for an authorization ticket to the server resource and sending the request for an authorization ticket to the authorization server, the request for an authorization ticket including an identification of the client;

in the authorization server and in response to a request for an authorization ticket, retrieving the access rights of the client from the directory server, generating a corresponding authorization ticket wherein the authorization ticket includes the access rights of the client and an identification of the client, and wherein the authorization ticket is encrypted with an encryption key derived from a password of the server;
in the authorization server, sending the authorization ticket to the client;
by operation of the client, sending the authorization ticket to the server in association with the operation request;
and in the server, decrypting the authorization ticket with the password of the server and obtaining the identification of the client and the access rights of the client to the server resource directly from the authorization ticket.

6. ~The improved method of providing client information to the server of claim 5, further comprising the steps of:
storing information regarding the client and required by the server in executing the operation request, in the directory server;
by operation of the client and in response to the request by the user for an authorization ticket, including an identification of the client information required by the server in executing the operation request in the request for an authorization ticket;

by operation of the authorization server and in response to the request for an authorization ticket, placing the information required by the server in executing the operation request into the encrypted authorization ticket; and in the server, decrypting the authorization ticket and reading the information required by the server in executing the operation request directly from the decrypted authorization ticket.