directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: OT kerberos, iwa and proxys
Date Sat, 02 Jun 2007 02:42:16 GMT
On 6/1/07, Marc Boorshtein <> wrote:
> Nope.  I know that the process of browser-->iis works, I wanted to put
> a proxy in between. Browser<-->http proxy<-->iis
> I know all of the spengo stuff is done in headers so I think its ok
> but I know this list has a lot of kereros knowledge so I wanted to get
> some input on if the proxy would interfere with the authentication
> process.

Hi, Marc,

If I understand your question, the short answer is that you should be
able to do this.  As you note, SPNEGO uses headers and errors from
HTTP that according to the standards should work.

There is a form of Kerberos ticket that is "proxiable" and when you
stated "... kerberos tickets could not be proxied ..." it made me
think of some advance use-case, but it sounds here like you mean an
HTTP proxy.

If you want to use SPNEGO to authenticate an end-to-end connection to
a destination web site through an HTTP proxy server, you should be
able to do that.  This is a supported operation in RFC 4559,  In section 6, they mention
this is not a mechanism for authenticating to proxy servers
themselves, but it doesn't sound like you want to do that.

When I read the following excerpt from section 6 of RFC 4559 ...

"A proxy that correctly honors client to server authentication
integrity will supply the "Proxy-support:
Session-Based-Authentication" HTTP header to the client in HTTP
responses from the proxy.  The client MUST NOT utilize the SPNEGO HTTP
authentication mechanism through a proxy unless the proxy supplies
this header with the "401 Unauthorized" response from the server."

... in an RFC authored by Microsoft, it makes me think that this is
likely behavior that you'll see in Internet Explorer ("the client").
At one time, Internet Explorer would not perform SPNEGO negotiation if
a proxy was configured; IE would simply not respond to SPNEGO
challenges.  This was a source of some of the belief that SPNEGO
through a proxy wouldn't work, but this was actually IE behavior, and
I'm saying the statement "The client MUST NOT..." probably means IE
won't.  So, this also needs to be supported by the proxy server.
Testing with modern IE and your proxy server of choice is in order,
but more recent documentation suggest that this is now supported, for
example this doc from Java jGSS, which mentions the possibilty of
Kerberos-authenticating to the proxy server and/or the destination web

Proxy-Authenticate is defined in HTTP/1.1 [1] but its use with SPNEGO
is not supported in RFC 4559.  Though, it appears that there is now an
established, if not standardized, way to SPNEGO authenticate to a
proxy server, eg the above jGSS doc.

Using jGSS in Java for SPNEGO, you'll either get a GSSException or the
name of a Kerberos principal.  You can take action based on these 2
conditions to either log the user into a web application or forward
them to a username/password form.  This assumes I'm right that you
want to end-to-end SPNEGO authenticate to a web site and not to the
proxy server.



[1]  Section 14.33,

View raw message