OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
c. The runtime decrypts the message containing the PTGT and returns
information about the source of the authentication information to the API.
(If the authentication information comes from the network security server,
then the login context is validated.)
3. Finally, the client invokes sec_login_set_context(), which enables child processes
spawned from the calling process to inherit the validated context.
In the walkthrough of user authentication in Chapter 23, we mentioned that one of the
functions of sec_login_valid_and_cert_ident() is to demonstrate that a valid trust path
exists between the authentication service and the host computer on which the principal is
logging in. After setting up and validating a login context, any application that sets
identity information for local processes should check to be sure that the server that
provided the certificate of identity is legitimate in order to demonstrate that the trust path
between the client and the authentication service is valid.
29.1.1 Validating the Login Context and Certifying the Security Server
Whereas a validated login context is one that is regarded as legitimate by the local
security runtime, a validated and certified login context is one that is not only regarded as
legitimate but also can be demonstrated to have been (in all likelihood, that is) issued by
a legitimate security server. Certifying that the security server is legitimate prevents
faked identity information from being propagated to local processes. For example, a
spurious server could collaborate with a dishonest user in order to obtain an identity that
conferred comprehensive permissions (for example, the root identity). With such an
identity, the dishonest user could gain access to sensitive local objects, such as key-
storage files for server principals that run on the host. (Servers running on other hosts
would not trust this principal, however, because it does not know their keys.) Of course,
if a spurious server can return to the application a ticket encrypted with the host’s secret
key, it means the server has access to the host’s key; but, if this is the case, network
security has already been seriously undermined.
When an application needs to certify the originator of a certificate of identity, it may call
sec_login_certify_identity(). This routine makes an authenticated remote procedure call
to the local security validation service of the dced daemon in order to acquire a ticket to
the host principal. If dced succeeds in decrypting the message containing the ticket, then
the server that granted the certificate of identity must know the host principal’s secret
key; this evidence indicates that it is a legitimate security server. Since dced runs with
the identity root (in order to access the host’s key), the process calling
sec_login_certify_identity() need not.
The sec_login_valid_and_cert_ident( ) is similar to sec_login_certify_identity(),
except that it combines the validation and certification procedures (and therefore, the
password of the principal that is logging in must be known to the process making this
call). The sec_login_valid_and_cert_ident( ) routine calls the security server for a
ticket to the host and attempts decryption. The process calling sec_login_valid_and_-
cert_ident( ) must have access to the host’s secret key, and so must run as root.
Note: Because system login programs should not set local identities derived from
an uncertified context, all login API routines that return data from an
29−2 Tandem Computers Incorporated 124245