[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using GSSAPI with specific providers
On Saturday 09 December 2006 02:16, Andrew Bartlett wrote:
> On Fri, 2006-12-08 at 16:09 -0500, Michael B Allen wrote:
> > GSSAPI only deals with authentication. As you point out NTLMSSP is
> > not supported by most (any?) GSSAPI implementations but that's not the
> > problem. GSSAPI could support NTLMSSP using the current model just fine
> > (although I don't know about the Schannel provider). The problem has
> > more to do with how SSPI integrates with host credential management.
> > Because everything goes through gss_cred_id_t you have a bunch of issues
> > regarding how to get credentials for use with GSSAPI and with how to
> > get credentials from GSSAPI for use with non-GSSAPI software.
Yes, these were the things I was wondering about.
> > For example, how do you get a gss_cred_id_t from a username and
> > password? Not defined. How does a service get the delegated credential
> > in a form that can be used with Kerberos aware software like libcurl or
> > the pgsql driver? Not defined [1].
> >
> > Also SSPI splits out a lot of functionality like encryption and signing
> > whereas GSSAPI tries to parameterize that with poorly defined concepts
> > like gss_qop_t.
> >
> > For the OP to implement SSPI in WINE GSSAPI alone will not even come
> > close.
>
> Possibly, as I don't know SSPI very well, but for Samba's purposes, it
> has done much better than the alternative: write it from scratch, or
> attempt to build it from the kerberos libs. That is why I gave kblin
> the advise to start with GSSAPI, particularly for the GSSAPI/SPNEGO/KRB5
> part. I would also be very interested in an end state where we have
> NTLMSSP provided into GSSAPI, possibly by Samba.
I'm still not sure if it's viable to wait for NTLMSSP to be picked up by a
GSSAPI
> I had hoped that WINE could use Samba's GENSEC in this, but I screwed up
> on licencing (the amount of code that required a re-licence was quite
> large, as GENSEC is very dependent on libs from the rest of Samba).
I'm not sure if it would make sense to get the NTLMSSP stuff into a seperate
library, like libntlm. If we could get this into a less restrictive license,
this could be used for GSSAPI, and from the to Samba or Wine. However, these
are all long scale plans, and I actually wanted to get some support for
negotiate and possibly kerberos into wine 1.0, and probably we're in for a
feature-freeze there soon.
I'm currently trying to figure out if it's worth to spend time on GSSAPI to
get this to work for me, or if I'm faster implementing SPNEGO myself. Andrew
Bartlett keeps trying to convince me GSSAPI works, but I'm not sure myself.
Cheers,
Kai
--
Kai Blin, <blin At gmx Dot net>
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Ninjas and Pirates agree: Cowboys suck!
PGP signature