DCE clients normally inherit valid credentials from the logged-in principal who invokes them. DCE servers normally need to establish an identity explicitly. The steps they take, and their relation to the Kerberos protocol, are described in this topic.
In actual practice, clients want to obtain a privilege ticket granting ticket (PTGT), since they want to prove not only their identities to servers, but also to provide their certified privileges (in the form of credentials). However, from the point of view of authentication, the principle is the same: the client needs some kind of TGT. For simplicity's sake, the following discussion pays little attention to the distinction between TGTs and PTGTs (as well as the many extra protocol steps involved.)
The terms credentials, authentication identity, and login context are often used to mean vaguely the same thing. Here however, we will use credential to mean a ticket held by an application. An application's credentials at any point typically consist of a number of cached tickets, including a TGT, PTGT, and a variety of service tickets. (Also, an application may have acquired more than one principal identity, in which case it will have credentials for each.) We will use authentication identity to mean the set of authentication-related data - including credentials - referred to by a login context. Finally, we will use login context to mean the opaque handle to authentication-related data that applications use.
An instance of authentication identity data in its various states is represented to an application as an opaque login context (sec_login_handle_t). An application obtains an authentication identity by calling sec_login_setup_identity( ), which returns a login context containing the TGT data. An application validates the identity by passing the login context to sec_login_validate_identity( ). Parts of the TGT obtained by sec_login_setup_identity( ) are encrypted using the requesting principal's key, obtained from the registry. The sec_login_validate_identity( ) routine requires the principal's key (from the keytab) to perform the decryption. Once this has occurred, the client runtime also performs the further steps necessary to acquire a PTGT and other tickets.
The setup and validation operations are separate in order to minimize the amount of time that the application needs to maintain the principal's key in its address space. Applications obtain the principal's key by calling sec_key_mgmt_get_key( ). The call to sec_login_validate_identity( ) destroys the key in place before returning. Applications should not violate the intention of this design by keeping the key in memory longer than necessary. That is, they should make the required calls strictly in the sequence illustrated in the following code fragment:
sec_login_setup_identity(prin_name, sec_login_no_flags,
&login_context, status);
sec_key_mgmt_get_key(rpc_c_authn_dce_secret, keytab,
prin_name, 0, (void**)&keydata,status);
sec_login_validate_identity(login_context, keydata,
&reset_pwd, &auth_src, status);
These calls are bundled into the dce_server_sec_begin( ) routine.
Once an authentication identity has been obtained and validated, an application that intends to use the identity for authenticated RPC normally turns it into the default login context by calling sec_login_set_context( ). As the default login context, an authentication identity is implicitly available to authenticated RPC calls made within the same process. An application, such as a client, that inherits an authentication identity inherits it as the default login context.