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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
