OSF DCE Application Development Guide--Introduction and Style Guide

Security

system access control to the key storage (typically a so-called keytab ﬁle) for the DCE

principal identity used by the server. However, since servers normally also need to

acquire credentials (in order to behave as clients of other services), application

programmers need to think carefully about how the server identity is acquired. In

general, it is not satisfactory to have servers run with credentials inherited from human

logins. For one thing, this requires the server to share keys with human users. This

means that the server either needs to have access to the default key storage used by

human principals (typically the default keytab ﬁle, probably owned by root) or it needs

to keep separate copies of user keys in local storage. Both of these schemes decrease the

security of keys, and the latter makes key management difﬁcult.

A straightforward scheme that meets these requirements is to have the server identity

supplied by the invoker (or a conﬁguration ﬁle) and have the server assume this identity

via a series of security service calls. The only administrative overhead is in establishing

at least one principal and the required keytab ﬁle. This is typically handled through

dced facilities.

3.3.3 Obtaining an Authentication Identity

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 section.

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 certiﬁed

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

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.

124246 Tandem Computers Incorporated 3−7