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 uncertified context issue a warning.