Delegated creds and SPNEGO
Nicolas.Williams at sun.com
Thu Aug 27 11:54:16 EDT 2009
On Wed, Aug 26, 2009 at 10:39:51PM -0700, Love Hörnquist Åstrand wrote:
> 26 aug 2009 kl. 22:07 skrev Nicolas Williams:
> >You must first store them somewhere with gss_store_cred(), so that
> >you can re-acquire; gss_store_cred(), like gss_acquire/add_cred() and
> >GSS_C_NO_CREDENTIAL, refers to the "current credential store".
> >Setting up credential stores and changing the current credential
> >store are outsire the scope of the GSS-API and really are
> >OS-dependent matters (e.g., putenv("KRB5CCNAME=...")? setuid()?
> >setup keyrings? PAGs? all OS-specific).
> gss_store_cred() is mostly unusable for just that reason, you can't
> use it inside a multi threaded application, and you are not sure how
> it will affect other processes if you call it. for example, two proxy
> smb fileservers store credentails for the same user, one might
> overwrite credentials for another process.
That's not necessarily true. For example, it's not true on Linux, since
you can setup your per-thread keyrings appropriately and off it goes.
And we could introduce a notion of credential store handles. This would
a) functions to create and release credentials stores;
b) a function to get a handle to the current credential store, and one
to set the current credential store to a given handle;
c) new versions of gss_acquire/add/store_cred() that take a credential
d) OS-specific functions for finding and manipulating other processes'/
threads' notion of current credential stores.
> >Our special case does not actually check for the SPNEGO OID. It's a
> >very simple special case (if (have_deleg_cred && actual_mech !=
> >initial_context_token_mech) then expect the mech to have returned a
> >mechglue cred, not a mech cred). It could use a tiny tweak for the
> >case of composite mechs (instead of actual_mech !=
> >initial_context_token_mech it needs to check that
> >initial_context_token_mech is equal to or a prefix of actual_mech).
> Then you force all composed mechs to use mechglue layer credentials,
> so they can't have their own credentials. Somethings that you
> recommend doing for gss_acquire_cred (ie defer acquire until later)
I got the sense of the check backwards, sorry, it should be:
if (have_deleg_cred && actual_mech != init_ctx_tok_mech &&
expect deleg cred to be a mechglue cred;
A stackable mech that returns a composite mech as the actual_mech will
be able to (will have to) have its own wrapper for the delegated
More information about the krbdev