Getting a gss-api credential handle from a userid and password

[Wyllys Ingersoll]

Il-Sung Lee wrote:
> Hi,
> 
> I have a basic question that I hope someone can answer.  I'm curious to
> know how an application would typically get a gss-api cred handle to use
> with gss_init_sec_context() if the principal name and password are provided
> as input (and assuming that the specified principal is different than the
> one associated with the default login context).  I would assume that
> krb5_get_in_tkt_with_password() would be used to obtain the krb5 cred
> handle but how would that be translated into a gss_cred_it_t data type?
> 

Acquiring initial creds is not handled by GSSAPI.  The underlying
mechanism (krb5 in your case) is expected to get the creds from
the credential cache which gets created when one runs 'kinit'
(for example).

It is better to acquire your initial creds outside
of the GSSAPI application so that the GSSAPI app doesn't
need to worry about it.

If you decide to break the abstraction and have your program
use a mix of KRB5 calls and GSS-API calls, then you can create
a cred cache before calling gss_init_sec_context by using
the krb5_get_init_creds_password, krb5_cc_initialize, krb5_cc_store_cred.
This would store the cred in the user's standard cred cache.
Later, when gss_init_sec_context is called, that cred cache
would be read and put into the gss_cred structure internally,
your app doesn't need to worry about doing that part.

Keep in mind that this is not a very portable solution for
several reasons.  The MIT Kerberos API is not standardized
and those calls may or may not be available if using another
vendors Kerberos libraries.  GSSAPI is able to handle
security mechanisms other than Kerberos, so making the
assumption that Kerberos is the only mechanism you will
need could limit your application's extensibility in the
future.

-Wyllys