hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Need clarification on the auth backend design for HTTPCLIENT-1625
Date Sat, 14 Mar 2015 22:01:55 GMT
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: 

If you think you can add valuable information, feel free to drop me some 

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.



To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message