W3C home > Mailing lists > Public > www-lib@w3.org > April to June 2004

Re: Kerberos authentication in libwww?

From: Steinar Bang <sb@dod.no>
Date: Tue, 01 Jun 2004 13:20:49 +0200
To: www-lib@w3.org
Message-ID: <87pt8jplri.fsf@dod.no>

>>>>> Steinar Bang <sb@dod.no>:

> I'm trying to see if it's possible to implement support for HTTP
> Kerberos authentication, as used by Microsoft[1] in libwww.

> The questions I'm currently searching for answers to, are:
>  1. is the gssapi-data binary chunk mentioned in [1] something that
>     can be used directly in the C-binding to GSSAPI[2]?

I've been looking at what libcurl does, in its Kerberos support.  From
the code http_negotiate.c source file, it looks like it uses something
called SPNEGO to handle the binary chunks.

I haven't yet figured out whether SPNEGO is an API, or just the name
of a way of doing things.

The modgssapache project[4], includes a library called fbopenssl,
which has functions that matches the calls done from http_negotiate.c
in libcurl.

The modauthkerb project[5] has in its source code a directory called
spnegokrb5 which I guess is an SPNEGO implementation.  But in this
directory I can't find the function calls used by libcurl.

>  2. can the Windows native security API, SSPI, use the gssapi-data
>     binary chunk in[1]?

There is SPNEGO support in SSI[6].

But this API doesn't seem to have the same functions as those used in
libcurl?  At least I couldn't find the parseSpnegoTargetToken()
function that fbopenssl implements, there.

- Steinar 

> References:
> [1] <http://www.ietf.org/internet-drafts/draft-brezak-kerberos-http-00.txt >
> [2] <http://www.ietf.org/rfc/rfc1509.txt >
[3] <http://www.wedgetail.com/technology/spnego.html >
[4] <http://modgssapache.sourceforge.net/ >
[5] <http://modauthkerb.sourceforge.net/ >
[6] <http://msdn.microsoft.com/library/en-us/dnsecure/html/http-sso-3.asp?frame=true#http-sso-3_topic2 >
Received on Tuesday, 1 June 2004 07:20:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:56 UTC