Mechanism extensions and the GSSAPI
kwc at citi.umich.edu
Thu Apr 29 11:09:00 EDT 2004
I agree with Nico that this is an excellent survey of the options.
> Here is what I believe the goal is. We want to find a way to have
> general extensions to GSSAPI mechanisms. Sun and apparently other
> parties as well would like to have the API between the multi-mechanism
> glue layer and the mechanism implementation be the GSSAPI. That means
> that any extensions we need to the glue layer need to be things we are
> willing to standardize. It might also mean that there can be no
> up-calls from the mechanism to the glue layer.
Yes, I agree this makes the life of the "core glue" library sane.
> Shim around Ioctl
> Mechanisms could provide a shim library that exports
> mechanism-specific APIs that end up calling the appropriate gss_ioctl
> function. That means that the responsibility of encoding the
> arguments is now the mechanism's rather than the application's. This
> proposal is as easy to use as the upcall approach although it is as
> hard to write for mechanism authors as the ioctl approach.
> This has the same disadvantage of the ioctl approach if multiple
> objects are used.
> This approach solves the dynamic linking problem in that there is no
> reason the shim cannot be in its own dynamic object.
I think I agree with Nico that this seems like the best option, but
let me see if I fully comprehend.
- When building the application, you need to know whether it is
linking against a single-mechanism gssapi implementation or a
multi-mechanism glue layer. Either way, it's interface doesn't
- If the app is linking directly with the single-mech
implementation, and uses mech-specific functions, it all happily
- If the app is linking with the multi-mechanism "core glue" and
uses mech-specific functions, it needs to know to link with the
mech-specific "glue shim(s)" and not directly against the mech-specific
library. (i.e. the "core glue" library shouldn't have to know about
mech-specific glue shims.)
Is this what you were thinking?
More information about the krbdev