[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-mechanism gssapi
>One of the other issues with the application calling mechanism-specific
>APIs has to do with passing of the context or cred. If there is a mechglue
>it will most likely have defined its own structure for the contect or
>cred, which contain pointers to the underlying context or cred for all
>the mechanisums it is fronting. The mechglue would then take care of
>passing the correct context or cred. But if the application bypasses the
>mechglue what does it pass for the contect or cred?
>How do you plan on handling this?
We solved this using the GGF API to punch through the glue context.
gss_krb5_compat_des3_mic(OM_uint32 *minor_status, gss_ctx_id_t ctx, int on)
buf = on ? 1 : 0;
value.length = 1;
value.value = buf;
>Your example of getting the name of the credentials store is one that
>the GSI ran into. Rather then calling mech specific routines the
>GGF GSSAPI extensions added the generic gss_export_cred that could return
>a handle to the stored credentials, suitable to be used with putenv. i.e.
>With Kerberos it would return "KRB5CCNAME=FILE:/tmp/krb5cc_uid" or whatever
>is the handle for the cache. With the GSI it would return "X509_USER_PROXY=/tmp/..."
NOted, but not yet implemented.