Exporting gssapi context, take two
Nicolas.Williams at sun.com
Wed Apr 28 17:22:49 EDT 2004
On Wed, Apr 28, 2004 at 04:04:53PM -0500, Douglas E. Engert wrote:
> Nicolas Williams wrote:
> > On Wed, Apr 28, 2004 at 01:46:55PM -0500, Douglas E. Engert wrote:
> > Generic extensions should be based on generic extension objects defined
> > by IETF (or other) specifications and identified by OIDs
> > (runtime-typing, if you will).
> I agree. And I really don't like the use of the mech specific interfaces.
> As it makes it harder to use arbitrary mechanisms if the application still
> has to link in mech specific routines. Although I don't see how one could
> mandate not allowing them. There will be some cases that are missed.
> We should try and learn form experience and try and get a list of all the
> known mech specific routines that have ever been used! We might find
> that many of these could be handled by new generic routines. The saving
> of the delegate credential is a prime example.
Yup. Though I wouldn't necessarily want to standardize our GSS
authorization interfaces (informational RFCs might suffice)...
> > I think the interfaces to mechanism-specific-but-platform-independent
> > extensions should be platform-independent. This is not a slam dunk
> > argument for the runtime-typing approach (as I'm sure that Sam will
> > point out), but it's a pretty good argument, I think.
> > And while this gss_get_mech_<object>() approach can work, whether the
> > result is platform/inplementation-independent will depend on the
> > interfaces that operate on the mechanism objects. Also, the mechglue
> > layer should do object handle validation and save the mechanisms the
> > trouble of doing it too, but your proposal means that the mechanisms
> > should do handle validation too.
> But there may not be a mechglue layer, therefore each mech needs to
> do all the checks.
True, but that could be a compile-time option that you might turn off if
you knew you were going to use the mech with a mechglue layer.
> > I still prefer the other approach; I may end up compromising on this
> > eventually, but I want to hear more about why one way is better than the
> > other.
> > > There would be one of these routines for the context too.
> > Since the API and SPI correspond there are actually three objects you
> > might want to do this for: names, creds, security contexts.
> I forgot the names. Any others?
No, just names, creds and contexts.
I doubt we'll want to extend the OID, OID set and/or buffer types :)
More information about the krbdev