[EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

[Nebergall, Christopher]

Thank you for your response it helped a great deal.     

>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

Ok, so the gss_accept_sec context in mod_auth_kerb can do restricted delegation/S4U2Proxy almost transparently if its creds are acquired using usage = GSS_C_BOTH, and it has TGT for its own creds available.  Correct?

My use case also requires the use of S4U2Self in mod_auth_kerb - so a Kerberos cred cache is available even if mod_auth_kerb didn't do the authentication - it instead was done by a different apache module such as mod_auth_radius or shibboleth.   So I would need to modify mod_auth_kerb so it supports doing S4U2Self and manage the cache, when it itself didn't authenticate the user - it just gets the identity from the apache request rec.  Does that make sense? 

-Topher
-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Tuesday, March 12, 2013 9:21 PM
To: Nebergall, Christopher
Cc: kerberos at mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

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