SPNEGO: Subsequent Calls after a Successful Negotiation and Authentication

Question

Over the last few days I have built a proof-of-concept demo using the GSS-API and SPNEGO. The aim is to give users single-sign-on access to

Answer 1

On re-reading my question, the question I was really asking was:

a) Is the overhead of SPNEGO significant enough that it makes sense to use if for a authorisation only, and that "something else" should be used for subsequent service calls?

or

b) Is the overhead of SPNEGO NOT significant in the greater scheme of things, and can be used for all service calls?

The answer is: It depends on the case; and key to finding out, is to measure the performance of service calls with and without SPNEGO.

Today I ran 4 basic test cases using:

1. a simple "ping" type web-service, without SPNEGO
2. a simple "ping" type web-sevice, using SPNEGO
3. a call to the application's login service, without SPNEGO
4. a call to the application's login service, using SPNEGO

Each test was called from a ksh script looping for 60 seconds, and making as many calls via CURL as possible in that time.

In the first test runs I measured:

Without SPNEGO

• 15 pings
• 11 logins

With SPENGO

• 8 pings
• 8 logins

This initially indicated that using SPNEGO I could only make half as many calls. However, on reflection, the overall volume of calls measured seemed low, even given the poorly specified Virtual Machines being used.

After some googling and tuning, I reran all the tests calling CURL with the -4 flag for IPV4 only. This gave the following:

Without SPNEGO

• 300+ pings
• 100+ logins

With SPNEGO

• 19 pings
• 14 logins

This demonstrates a significant difference with and without SPNEGO!

While I need to do further testing with real-world services that do some backend processing, this suggests that there is a strong case for "using something else" for subsequent service calls after authentication via SPNEGO.

In his comments Samson documents a precedent in the Hadoop world, and adds the additional architectural consideration of Highly Distributed / Available Service Principals