hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Need clarification on the auth backend design for HTTPCLIENT-1625
Date Fri, 13 Mar 2015 17:05:23 GMT
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.


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

View raw message