[EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

Simo Sorce simo at redhat.com
Tue Mar 12 23:20:39 EDT 2013


On Tue, 2013-03-12 at 22:46 +0000, Nebergall, Christopher wrote:
> I looked through the patches and I'm unclear how it is meant to work.
> I see no new gssapi or krb5 related functions related to
> http://k5wiki.kerberos.org/wiki/Projects/Services4User.  What are the
> outputs of the code when a user makes an HTTP request?

You get a ccache created by mod_auth_kerb and KRB5CCNAME variable set in
your CGI.

>   Will a CGI have access to a credentials cache for the user, so it
> can just call gss-init-sec-context like normal, or will the CGI just
> have access to a cred cache for the impersonation account - and the
> CGI must do the heavy lifting to impersonate the user using the
> Services4User functions mentioned above?

CGI just needs to use gss_init_sec_context using the ccache provided by
mod_auth_kerb

> In other words if you have two processes 1) the server which interacts
> with the user, and 2) a client process on the server which does
> something on the user's behalf using Kerberos - which process would
> normally call gss_acquire_cred_impersonate_name?   1 or 2?

IIRC It is done for you by mod_auth_kerb.
All you need to do in the client part is use the ccache to obtain the
ticket for the target service and the impersonation part is taken care
off for you transparently by GSSAPI.

> Sorry, I'm new to this topic, so I may be missing something
> fundamental about how it is meant to work.

The fact is that there are a few ways in which this work, when
mod_auth_kerb is used, the action of exporting a ccache file with the
received credentials is basically equivalent to calling
gss_acquire_cred_impersonate_name

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the Kerberos mailing list