OSF DCE Application Development Guide--Core Components

DCE Security Service
4. The Privilege Service decrypts the ticket sent to it, learning both the identity of
the user and the conversation key it will use to encrypt its response. The Privilege
Service believes the identity is authentic because the ID information was
encrypted under its own secret key, and no principal other than the
Authentication Service could have encrypted the information using this secret
key. Because the Privilege Service trusts the authenticity of the user’s identity, it
prepares a Extended Privilege Attribute Certificate (EPAC).
The EPAC describes the user’s privilege attributes and any extended attributes
that are associated with the user. The EPAC (or EPACs in case of a delegated
operation) is sealed with an MD5 checksum. (Delegation is described in the
chapter titled "The Extended Privilege Attribute API.") The Privilege Service
produces a PTGT that contains the EPAC seal, a third conversation key, and in
the case of a delegate operation, the EPAC seal encrypted in the key of the
Privilege Server. This encrypted seal is called a "delegation token." (The
Authentication Service and Privilege Service cooperate to prepare the PTGT,
although the illustration only shows the Privilege Service preparing it). The
EPAC itself is carried outside the PTGT. The EPAC seal is used to verify the
integrity of the EPAC data for authenticated RPC calls.
The PTGT envelope is encrypted using the second conversation key and also
includes the third conversation key. (The Authentication Service supplies the
third conversation key, although the illustration does not show this detail.)
5. The Security client runtime decrypts the PTGT envelope using the second
conversation key, and learns the third conversation key. It cannot decrypt the
PTGT itself, since the PTGT is encrypted under the secret key of the
Authentication Service.
23.2.1.3 The Login Context
At this point, the Security Server has authenticated the user’s identity, and as a result,
the user has been able to acquire information about its privilege attributes that the
Privilege Service has certified. The client now calls sec_login_set_context() to set the
login context (a handle to this user’s network identity and privilege attributes) to the
identity that has been established. Henceforth, processes invoked by this user assume
the user’s login context, and among these processes is the client-side of an application
that is the subject of the rest of the walkthrough.
23.2.1.4 Identities in a Delegation Chain
When a user who has initiated delegation (with sec_login_become_initiator), makes
an authenticated RPC call to the next member in a delegation chain (the intermediary),
the initiator passes its EPAC and its PTGT, which contains the seal and delegation
token. The intermediary then invokes sec_login_become_delegate or
sec_login_become_impersonator, passes to the Privilege Service the authorization
information (EPAC and delegation token) it received from the initiator, and requests the
23−16 Tandem Computers Incorporated 124245