Re: Exporting gssapi context, take two

["Douglas E. Engert" <deengert@anl.gov>]

Sam Hartman wrote:
> 
> In a side discussion with Nico, he indicated that he wants the
> mechanism not to depend on special interactions with the glue layer.
> 
> We may have incompatible requirements.  I'll send out a message later
> today exploring the space of possible options.

One option is to define in the gssapi revised standards a routine
to return the underlying mech specific handle for the cred.  

 gss_get_mech_cred(OM_uint32 *minor,
                   const gss_cred_id_t oldcred,
                   gss_cred_id_t *mechcred,
                   gss_OID *mech)

When implemented by a mech it would do *mechcred = oldcred;
 
When implementred by a glue layer, it would call the underlying
mech's version of this routine, passing as the oldcred what it does
now with other other routines that need a cred.  

A application which needed to call a mech specific routine like
krb5_gss_*  that needed the cred, would first call gss_get_mech_cred

Thus the application would work with or without a glue layer(s), and the
mech specific routine would always get the mech version of the cred. 

There would be one of these routines for the context too. 

(It could be written to return the cred directly, ands thus could be used
in a macro.)

> 
> I assert axiomatically that we need to support mechanism specific
> extensions in a manner that is easy for application authors to use.
> Nico requires that the API between the mechanism and the glue layer be
> GSSAPI.
> 
> Let's see if we can find a way of meeting both of these goals.

I think this does. 

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444