OSF DCE Application Development Guide--Core Components

Authentication

addition of its identity to the delegation chain. The Privilege Service uses the delegation

token, which is a seal over the EPAC encrypted in the Privilege Service’s key, to

determine whether or not to certify the initiator’s credentials. If the initiator’s

credentials are valid, the Privilege Service generates a new seal and delegation token to

seal the initiator’s and the intermediary’s EPACs. Again, the delegation token is

encrypted in the Privilege Service’s key. The intermediary’s authorization information

now includes both EPACs in the delegation chain and a PTGT that contains the EPACs

seal and delegation token. The subsequent additions of identities to the delegation chain

are handled in the same manner, with each intermediary’s identity being added to the

chain.

23.2.2 A Walkthrough of DCE Application Authentication using

Authenticated RPC

This section explains how DCE Security authenticates an application to which the

application developer has added Authenticated RPC calls. It is a continuation of the

walkthrough in the previous section.

Note: Refer to Figure 23-5 as you read the following steps.

1. Having been authenticated and having acquired a PTGT, the user now invokes an

application. The client side of the application calls

rpc_binding_import_begin( ), rpc_binding_import_next( ), and the like. These

calls specify the remote interfaces required by the client for the application.

2. The Cell Directory Service returns the client binding handles to the speciﬁed

interfaces. (For this example, we have arbitrarily chosen the binding model in

which the client consults the CDS for the server principal name.)

3. The client next sets authorization information for the binding handles by calling

rpc_binding_set_auth_info(). Among other parameters that it sets,

rpc_binding_set_auth_info() sets the authentication protocol, the protection

level, and authorization protocol for the binding handle corresponding to the

remote interface. In this case, assume the following: the authentication protocol

(authn_svc parameter) is DCE Shared-Secret Authentication; the protection level

(protect_level) is Packet Privacy (all RPC argument values are encrypted); and

the authorization protocol (authz_svc) is DCE Authorization (an EPAC contains

UUIDs representing the client’s privilege attributes, and the server is most likely

to compare this information with the ACLs protecting the objects of interest in

order to determine the principal’s authorization).

124245 Tandem Computers Incorporated 23−17