Am 2015-03-13 um 18:05 schrieb Oleg Kalnichevski:
On Fri, 2015-03-13 at 15:49 +0100, Michael Osipov wrote:
Hi Oleg,
finally I am able to respond. Way too late. A cold has knocked me off
for 10 days.
Same happened to me a month back. It was not fun. Take it easy.
...
What about the UserTokenHandler? Do I need to provide some
principal back after successful auth, if yes how do I pass that?
The user identity / security principal used by GSS represents the
authenticated (logged on) user and essentially applies to all
connections open by the user, does not it? Can one create an instance of
GSSContext with a different user principal or is it always the same
authenticated (logged on) user? If not, persistent connections cannot be
accidentally re-used by someone with a different user identity /
security principal and as far as HttpClient is concerned are state-less.
It is not always that clear. Let me explain why: if we say that the
authentication is connection-bound, we still have no clue -- and
shouldn't make any assumptions -- how the server internally maintains
that information. The server (e.g. IIS) can/will bind against the HTTP
connection and won't bother again until the connection is disposed.
Where as in Tomcat (connection object is not available in a valve) will
re-authenticate every single request roundtrip. So, I will not make any
assumptions about it but simply respond to the server as soon as it will
require me to. To answer the first question, yes it does apply if the
server does so.
To answer the second question, I'd like to sketch a usecase for which I
want to provide a proper implementation: Webapp running on a Servlet
Container, requesting some resources on a backend system. A connection
pool to the client has been added. All resources are accessed with the
default system account on that machine (e.g., /etc/krb5.keytab). Now, in
some cases you have your webapp protected by SPNEGO too and the client
sends you his ticket along with his delegated credential. What you can
do now is to re-use his GSSCredential and execute a request on behalf of
the user with a previously authenticated connection on the backend
server. Since the pool is opaque to the controller in the webapp, you
won't notice. If the server won't prompt you, you won't authentiate
anyway. To answer the second question, yes you can have arbitrary
GSSCredentials perform any requests which you might decide at runtime.
Karl Wright even depicted that usecase in his very first mail when I
introduced myself.
That looks quite complex. Anyway, if you can think of a bit of
information that can uniquely identify the user in each scenario, the
problem is essentially solved. All we need is a token uniquely
representing user identity.
I am yet not completely sure about it but I guess that will resolve at
some point.
For now, I have created a little writeup which tracks all necessary
information for me:
http://people.apache.org/~michaelo/issues/HTTPCLIENT-1625/
If you think you can add valuable information, feel free to drop me some
lines.
One more thing: When an AuthScheme instance has completed the
authentication, can this object be reused? E.g., redirects on the same
server during one GET request.
Thanks,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
