tion is a particular type of rights delegation which expressly identifies the entities involved in the delegation and does not inherently require a global namespace. "Rights" are sometimes referred to in connection with "permissions"; the two terms are used interchangeably herein. In one embodiment, the invention operates as follows.
A user logs in and sends an authentication request to one of the Distributed Deputization Points ("DDPs"). The "user" may be a user task for a human who is using the system, or it may be a system task which is created by the system software or by some application program. Login might be unnecessary for system tasks. The authentication request identifies the user by a user name, a user ID number, or the like. Familiar or novel authentication mechanisms may be used, including biometric readings, a smart card, and so on. The authentication request may include a logon certificate, a password, or another credential to prove that the user has the right to operate under the specified user name or user ID.
Assuming the credential and/or other authentication information is accepted by the DDP as legitimate, the user receives an authentication response. The authentication response includes an indication that the user is now authenticated, and may also include a credential identifying the permissions granted to the user as a result of the authentication. As noted, tasks created by the distributed computing system may also authenticate themselves to a DDP. In particular, deputized agents previously created by or on behalf of a DDP can in turn authenticate themselves to the same or another DDP in order to create additional deputies.
The authenticated user then sends the DDP a deputy credential request. The deputy credential request may contain the public key of the proposed deputy, or it may identify the deputy so the DDP can request the deputy's public key from a repository in a public key infrastructure. Alternatively, the DDP may be responsible for seeing that a deputy is created and for obtaining the identity of the deputy from the operating system. When the user identifies the deputy, the deputy credential request also contains the private key of the proposed deputy encrypted with the user's public key and a user credential which identifies the user and proves it is authorized to create deputies.
The maximum life span of the deputization or another expiration event may also be provided to the DDP by the user, or the DDP may use a default event or even override the event requested by the user. In some versions, no maximum life span or other predefined expiration event is specified and each right granted through a deputization is recognized until it is expressly revoked.
The permissions to be granted to the deputy may be specified to the DDP by the user. These permissions must be the same as, or a proper subset of, the permissions held by the user. The DDP can be configured to override the permissions requested by the user if system administrators determine that is appropriate. If the deputy credential request does not specify the deputy permissions, the DDP may use a default value or simply make the permissions the same as the user's.
In response to the deputy credential request, the DDP creates a deputy credential. The deputy credential contains the user identity, permissions being delegated by the user, the private key of the deputy encrypted with the user's public key, a deputy certificate, and the DDP's digital signature. The deputy certificate contains the public key of the deputy in a certificate minted by the DDP or some other well-known DDP, deputy credentials from the DDP, deputy permissions, and the DDP's digital signature. The deputy
certificate may also contain a maximum deputy certificate life span that indicates when the deputization expires. Passage of time is not the only event that can trigger an expiration. Other deputization expiration events include, for
5 instance, decommissioning an employee through the Human Resources department, an explicit or forced expiration by an administrator, or a database corruption event.
A user may have zero or more deputies, and each deputy may have zero or more individually deputized functions or
10 deputies. Including the user identity in the deputy credential ensures that the user can be held responsible for the activities of its deputies. Including the private key of the deputy encrypted with the user's public key allows the user to sign deputized functions in a way that makes it possible to trace the actions of both a particular user and a particular deputy
15 in order to hold the correct party responsible for the activities of a given deputized function. The DDP signatures make it possible to hold the DDP involved responsible, and also make it possible to detect alterations in the deputy certificate and/or the deputy credential after the credential and certifi
20 cate are provided by the DDP. The deputy permissions specify what the deputy can and cannot do, and the deputy credentials show that the permissions are accurate.
The user can deputize functions with the deputy credential. Each deputized function includes some code or script to
25 run, the deputy certificate, and a signature created using the deputy's private key (which is known to the user). A deputized function may also specify which permissions are being granted. Permission specification is not needed if the deputized function is going to run under the domain of the
30 deputy, that is, with the same permissions as the deputy. Otherwise, the deputized function becomes a deputy itself and must be authenticated at the target with a deputy credential which specifies the permissions. Any access point that can authenticate the deputy certificate can authenticate
35 the deputized function, allowing it the permissions specified in the deputy certificate. Multiple deputy certificates can be associated with a single deputized function or other deputy, in which case the permissions allowed are the union of the permissions in whatever individual deputy certificates are
Unlike key-oriented approaches to delegation, deputization associates particular acts of delegation with particular entities and does not require a global namespace. Creating deputies in this manner has several advantages. Entities
45 responsible for particular actions can be more readily identified. A delegation of authority can be made to persist even after the entity which delegated the authority logs off the system, since the deputy can persist. Delegations can also be made from one namespace to another, and across heteroge
50 neous network boundaries, by creating deputies in the target namespace and/or network. Other features and advantages of the invention will become more fully apparent through the following description.
BRIEF DESCRIPTION OF THE DRAWINGS
To illustrate the manner in which the advantages and features of the invention are obtained, a more particular description of the invention will be given with reference to the attached drawings. These drawings only illustrate
60 selected aspects of the invention and thus do not limit the invention's scope. In the drawings:
FIG. 1 is a diagram illustrating one of the many distributed computing systems suitable for use according to the present invention.
65 FIG. 2 is a data flow diagram illustrating selected components of the inventive distributed computing system and information communicated between those components.