Kerberos/SPNEGO in Gatling 3.0


I’m trying to write a Gatling load test scenario for a service that requires Kerberos authentication.

It seems one of the major items of 3.0 was to replace the old HttpClient, so documentation and user posts I have found on the topic don’t seem to be directly applicable anymore. As an example, HttpHelper.buildRealm no longer seems to exist and as far as I can tell the old Kerberos support was ultimately provided by the Apache client. I therefore wanted to check if anyone had any pointers on how to proceed wrt implementing this ourselves (and also, just a quick check to ensure I’m not simply overlooking support that’s actually still there). Disclaimer: I know Java/Kerberos reasonably well, but have very limited Gatling and Scala experience.

For adding support into the HttpClient itself, it seems the HttpProtocolBuilder.authRealm with the addition of a new KerberosRealm class might be a good starting point, following the examples of the existing DigestRealm and DigestAuthHandler. However, there appears to be no way of registering additional handlers currently. Would adding an additional if (realm instanceof KerberosRealm) {…} in be the correct way to set this up? Any other considerations/things to look out for? I’m sure a lot of additional details will emerge while working on it as well.

An alternative solution, perhaps, would be to just write the SPNEGO exchange into the scenario itself. I.e. something like get("/login").header(“Authorization”, computeHeader(challenge)) or something to that effect. Subsequent requests would use the session cookie without triggering auth from that point anyway.

A third but not preferable option would be try to get this working “the old way” on Gatling 2.x for now, and transition to 3.x later.


Disclaimer: I know Java/Kerberos reasonably well, but have very limited Gatling and Scala experience.

Cool, we’re the exact opposite.

In fact, I personally never got the opportunity to work in an environment with NTLM/Spnego/Kerberos.
I ended up trying to implement support in AsyncHttpClient by forking a class from Apache HttpComponents and trying to emulate a server based on payloads I could find in blog posts… No really a bullet-proof solution, all the more as the devil is in the details and things built in the lab usually break down when faced to real systems.

In the end, I didn’t feel confident reproducing this mess in our new HTTP client, all the more as some users report from time to time that the support in Gatling 2 didn’t work for them.

There’s an open issue for this.

Then, I sadly don’t expect it to be implemented any time soon.

We’d need a way to test it. We can’t just accept a contribution and trust it to work out of the box.
I don’t even know if it’s possible without some Microsoft licence, which we can’t afford for an open source project.
The other solution would be to be able to contract with a customer who would grant us access to his environment.