Delegation and Protocol Transition

Sep 16, 2010 at 7:53 PM

Once a user has authenticated via Waffle, is it possible to call 3rd party web services using that user's credentials (via kerberos delegation or constrained delegation?)

Has any one tackled this?  If so, is it possible even if they authenticated using NTLM, perhaps by using protocol transition?





Sep 16, 2010 at 10:55 PM

It's certainly possible with some work.

First, I would figure out how to call any 3rd party web service using current (or specific) credentials. This would be standard stuff. There're plenty of examples in Waffle tests that manufacture the client-side WWW-Authenticate headers. For example, NegotiateSecurityFilterTests.testNegotiate implements the client side using JNA. There's a more in-depth discussion in this thread, including some pure Kerberos authentication. 

So, now that you can call some service with current credentials you need to have Waffle impersonate the calling user. If it could impersonate, then you would be running as the user inside a web application that's executed after authentication and could make the call to that thirdparty service. This is this workitem. I already wrote and committed the Impersonation code in JNA and already exposed it in Waffle's IWindowsAuthProvider. I didn't do the filter work, but that is the easier part. Maybe you can make it happen? :)

Sep 16, 2010 at 11:59 PM

I'm happy to work on this.  Is there a difference between impersonation and kerberos delegation?   I know that kerberos delegation has a 10 hour limit by default (Active Directory configurable) for how long a TGT can be used on behalf of a user.   Is impersonation subject to the same limits?

Are there any specific requirements for the user that runs the Tomcat service - anything that is needed to grant the user that runs Tomcat the right to do impersonation?


Sep 17, 2010 at 1:31 PM

Most of what I am going to write comes from here. I'll try to put it in plain English :)

You're doing impersonation, in technical terms you're trying to obtain an impersonation token that lets you impersonate and access network resources. There're multiple ways to achieve that.

Call LogonUser and request an Interactive logon session: you need a username and password and to do an interactive logon. This is not our scenario.

Use BASIC authentication and impersonation: this is straightforward if you're doing BASIC auth, you take the user's username and password out of the header and do a network logon, then impersonate. Waffle's BASIC auth filter does that (minus the impersonate call) to validate the user's credentials - then it just disposes of the obtained impersonation token.

Kerberos authentication and delegation: if the protocol chosen by the client is Kerberos and several other conditions are satisfied (your computer or service account is Trusted for Delegation in Active Directory and you have registered a Service Principal Name (SPN) for the service), what you get out of Waffle is a Kerberos TGT. You never see it, it's somewhere within the IWindowsIdentity that you obtained by implementing the server side of the Negotiate protocol (that's what Waffle does). You get an impersonation token just like out of any logon. Then you call impersonate, the rest of the magic happens in Windows.

Use Protocol Transition: when the client can't do Kerberos (eg. your server is not in an Active Directory or you're logging in with a local account or there's no SPN configured properly) you'll be doing NTLM (v2). The Negotiate protocol "negotiates" whether to do Kerberos or NTLM. Then, if certain conditions are satisified (described here) you can impersonate and call the remote service on behalf of the user. It's the same Impersonate process, except the token you were holding after NTLM looks nothing like the token that you got when doing Kerberos.

This entire thing boils down to an Impersonate call which puts your current Win32 thread into the context of the calling user - then you see what happens. This is all hidden from you by an API called SSPI, which makes Windows into a truly extensible authentication/impersonation/delegation framework.

Sep 17, 2010 at 11:53 PM

Thank you, this is exactly the information I needed.  You've been very helpful!

I asked what was going on under the covers because I need to know if this approach will be subject to the limitations involved in Kerberos delegation.   I think it's clear that it will.     If the user's SSO auth happens via Kerberos, we have a TGT.   If they login via NTLMv2, then protocol transition happens and behind the scenes there is still a Kerberos TGT.  This comes with a 10 hour time window (given default AD configuration) during which the app can continue to impersonate the user (assuming I hang onto that IWindowsIdentity somehow - I don't suppose it's serializable?).

That's a bummer for our app, it would be very helpful if our app if it could continue to impersonate that user indefinitely, but of course I can see why they don't want to allow that.