[Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using GSSAPI with specific providers
I'm also sending this to kitten (the GSSAPI working group mailing list).
On Fri, 8 Dec 2006 09:48:50 -0800
"Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:
> If you google "altman sspi gssapi sample" you can find references to
> example code for how to use SSPI and GSSAPI in a compatible way.
> SPNEGO is a supported mechanism for most current GSSAPI
> implementations (including the ones in the MIT and Heimdal
> implementations).
>
> I'm not sure how much of a subset the current GSSAPI implementations
> are. The one area I know to worry about is the ability to auto-
> negotiate from GSSAPI/SPNEGO/krb5 to GSSAPI/SPNEGO/NTLMv2 if needed.
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.
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.
Mike
[1] It has been suggested that a GSSAPI function be added to export a
Kerberos 5 credential cache file. The KRB5CCNAME environment variable and
credential cache file mechanism is not suitable for acceptors (e.g. HTTP
daemon cannot adequately protect ccache files). The creds should really
be hosted in memory controlled by the kernel. Then GSSAPI could add a
"save cred" flag that specifies that delegated credentials should be saved
there in a mechanism specific way that would also be accessible to other
non-GSSAPI aware code.
--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/