1983-01...@gmx.net wrote:
I have no usecase for this at the moment :-(, I only provide patches
for
stuff I suffer from at work.
The below looks like a use case to me.
As this [1] draft lays out Negotiate and Kerberos may apply to
connection or request level auth. We are just lucky that the first
gss_accept_sec_context makes the context complete in the SPNEGO
authenticator.
Some clients maintain the state and rely on the server to maintain the
connection state too. Tomcat does not do that which means that the
current SPNEGO authenticator has to issue a "Connection: close" after
successful auth. Otherwise the client will reuse the connection and
keep
sending requests w/o reauthenticating eventhough Tomcat requires to do
so. In this case I have a Wireshark capture where this exactly happens
and the clients traps in an endless loop and issues thousands of
requests performs a DoS.
Well, as long as there is support for connection storage should I file a
bug about that?
Go for it.
The connector has to close the connection in my opinion.
Not sure what you mean by that.
I guess there is a misunderstanding here. There are two issues to be filed:
1. The long-term support for a connection-based store.
2. The above described behavior of the current SPNEGO connector in Tomcat 7. A
DoS is possible when a client expects that the server has a connection context
on a persistent connection.
I was referring to the latter in the first place.
Michael
Hi.
This might be slightly OT, but I just wanted to mention that in a Windows domain context,
maintaining state at the level of the connection is essential. NTLM authentication
requires several back-and-forth exchanges between the client and the server, in sequence.
In the background, the server has to talk to a domain controller etc.
This is a very heavy authentication mechanism, so it is the connection which is
authenticated, to avoid having to re-authenticate (or at least verify the token) at each
subsequent request from the same browser/client.
That's also why NTLM authentication requires (or at least strongly suggests) keep-alive,
and also why there are limitations using this through firewalls etc.
As far as I know, some NTLM authentication mechanisms "fake" this by caching the client's
IP address and client-side port number. For example, if you use Jespa (www.ioplex.com)
under Tomcat, behind an Apache httpd front-end, you *must* forward the browser's client IP
address and port number over the httpd-tomcat proxy connection, so that Jespa can retrieve
the client's authentication status from this cache.
Which all may point to another logical issue :
If you were to implement a connection-level "object" in Tomcat to store such
authentication information, it may work if Tomcat is accessed directly by the client.
But if the client accesses Tomcat through a proxy, there is (I think) no guarantee that
the same proxy connection to Tomcat would always be used by the same client.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
