OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
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.
3.3.4 The Authenticated RPC Call
Once an application has either inherited or established a validated authentication
context, it establishes authentication for RPCs by annotating the binding handles on
which those calls are made. Clients do this by calling rpc_binding_set_auth_info().
No further action is required of the application: when an RPC is made on such a binding
handle, all further authentication is carried out silently by the RPC runtime.
The call to rpc_binding_set_auth_info( ) requires three pieces of authentication-related
state:
1. The authentication service to use: either DCE secret key or none.
2. The login context to use. Most applications will specify the default login context
(by setting the auth_identity parameter to NULL).
3. A principal name for the server being called.
Note that applications may need to establish a default login context even if they do not
explicitly call rpc_binding_set_auth_info() to set this context for a specific binding
handle. In particular, access to name and other services involves authenticated RPC
calls made by the runtime on the application’s behalf. In these cases, the application
does not have a chance to call rpc_binding_set_auth_info( ) explicitly. These implicit
calls therefore use the default identity for authentication purposes. It is mainly for this
reason that servers need to establish a validated authentication identity for the principal
3− 8 Tandem Computers Incorporated 124246