Oracle Solaris Security for Developers Guide

Acquiring Credentials in GSS-API

Before a security context can be established, both the server and the client must acquire their respective credentials. A credential can be reused until that credential expires, after which the application must reacquire the credential. Credentials that are used by the client and credentials that are used by the server can have different lifetimes.

GSS-API-based applications can acquire credentials in two ways:

In most cases, gss_acquire_cred() is called only by a context acceptor, that is, a server. A context initiator, that is, a client, typically receives credentials at login. A client, therefore, can usually specify the default credential. The server can also bypass gss_acquire_cred() and use that server's default credential instead.

A client's credential proves that client's identity to other processes. A server acquires a credential to enable that server to accept a security context. So when a client makes an ftp request to a server, that client might already have a credential from login. GSS-API automatically retrieves the credential when the client attempts to initiate a context. The server program, however, explicitly acquires credentials for the requested service (ftp).

If gss_acquire_cred() completes successfully, then GSS_S_COMPLETE is returned. If a valid credential cannot be returned, then GSS_S_NO_CRED is returned. See the gss_acquire_cred(3GSS) man page for other error codes. For an example, see Acquiring Credentials in Chapter 6, GSS-API Server Example.

gss_add_cred() is similar to gss_acquire_cred(). However, gss_add_cred() enables an application to use an existing credential to create a new handle or to add a new credential element. If GSS_C_NO_CREDENTIAL is specified as the existing credential, then gss_add_cred() creates a new credential according to the default behavior. See the gss_add_cred(3GSS) man page for more information.