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

1. To answer your first question, GSS-SPNEGO may include multiple round trips. It is not limited to just two. You should implement a session handling and upon successful authentication issue a session cookie that client should be presenting on each request. When this cookie is invalid, server would force you to re-authenticate. This way you would only incur negotiate costs when that is really needed.

2. Depending on your application design you can choose different approaches for authentication. In FreeIPA we have been recommending to have a front-end authentication and allow applications to re-use the fact that front-end did authenticate the user. See http://www.freeipa.org/page/Web_App_Authentication for detailed description of different approaches.

I would recommend you to read the link referenced above and also check materials done by my colleague: https://www.adelton.com/ He is author of a number of Apache (and nginx) modules that help to decouple authentication from actual web applications when used with FreeIPA.

Answer 2

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