[EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching
cneberg at sandia.gov
Wed Mar 13 13:39:10 EDT 2013
>>Is the connecting client doing any kerb auth at all?
>>I don't see a technical problem in his, however it is not clear to me why you would do all of this in mod_auth_kerb given you are doing no authentication there at this point.
No technical reason beyond reducing code duplication with mod_auth_kerb - my app would also be an apache module with has similar Kerberos config params and cred cache handling abilities exposed to the backend CGI's. It would also add the ability to create Negotiate tokens for downstream webservers contacted through mod_proxy.
Thanks for your help!
From: Simo Sorce [mailto:simo at redhat.com]
Sent: Wednesday, March 13, 2013 10:08 AM
To: Nebergall, Christopher
Cc: kerberos at mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching
On Wed, 2013-03-13 at 15:10 +0000, Nebergall, Christopher wrote:
> 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
> 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.
> 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?
I don't see a technical problem in this, however it is not clear to me why you would do all of this in mod_auth_kerb given you are doing no authentication there at this point.
Is the connecting client doing any kerb auth at all?
If not you may be better off (as in it being more flexible for you) doing the whole s4u2self+s4u2proxy dance within your application.
Simo Sorce * Red Hat, Inc * New York
More information about the Kerberos