PreviousNext

Identities in a Delegation Chain

When a user who has initiated delegation (with sec_login_become_initiator(~)) makes a authenticated RPC call to the next member in a delegation chain (the first intermediary), the initiator passes its PTGT (including EPAC, seal and delegation token) to the TGS, and receives an extended privilege service ticket (again containing EPAC, seal and delegation token) to the intermediary. This is passed to the intermediary. The intermediary then invokes sec_login_become_delegate( ) or sec_login_become_impersonator( ), passing to the privilege service the authorization information it received from the initiator (EPAC and delegation token), together with the intermediary's own PTGT (including the intermediary's EPAC, seal and delegation token).

The privilege service uses the two delegation tokens, which are seals over the initiator's and intermediary's EPAC encrypted in the privilege service's own secret key, to verify the authenticity of the EPACs. If these are valid, the privilege service creates an EPAC chain, consisting of the initiator's and intermediary's EPACs, and generates a new seal and delegation token for this EPAC chain, and returns to the intermediary a new PTGT containing this information. Thus, the intermediary's authorization information now includes both EPACs in the delegation chain and a PTGT that contains the EPAC chain's seal and delegation token. The subsequent additions of identities to the delegation chain are handled in the same manner, resulting in PTGTs with each intermediary's identity being added to the EPAC chain. Any such PTGT can be used to continue the delegation chain or to acquire a service ticket to the ultimate target server.