Spring Security Kerberos chained with basic

Question

I have a hopefully quick question about Spring Security.

I am looking for a solution to integrate security into our application which provides SSO but HTTP basic as well.

One of the automated pieces of our system can only support basic authentication and we are pretty locked into it. Currently we are targeting to use Kerberos for our SSO solution and then also support basic (for very restricted usage). All of this will protect RESTful web services that run through resteasy.

Does anyone see any inherent impossibilities in this solution of both Kerberos and BASIC chained together in spring security? We had problems with WildFly and undertow not being able to support multiple different authentication methods, that use HTTP response codes in their handshakes.

Thanks for the input

Answer 1

Since this question is a bit tough, I assume you are already familiar with the Spring Security Kerberos samples that show how to configure kerberos auth with a form auth as fallback. I have no evidence that it'll work but I think you should be able to chain your kerberos auth with basic auth without any problems. I share my thoughts on this...

Thought 1: FilterChains

The trick to support mulitple authentication methods is to set the order of the authentication filters correctly. If the order is wrong, the client could hang in the basic auth and might never reach the kerberos authentication filter, because the browser's basic auth dialog would pop up. This might depend a bit on how the basic auth provider and filters are implemented in Spring. Anyway, if the order is correct, the filter next in chain after the kerberos filter (the basic auth filter) will start its work.

Thought 2: Kerberos auth shouldn't break basic auth

The browser should treat the communication with the kerberos service provider different to the communication with the basic auth provider, since the protocols are different. The SAML communication runs in it's own namespace, thus in my opinion it shouldn't affect the basic auth communication which is based on authorization element in the HTTP header.

EDIT: Even if the assumption about the namespace doesn't play any role in the browsers behavior, step 6 in the sequence diagram will be a crucial point. When the filter chaining is correct, Spring should return a 401 response like 401 - Access denied - WWW-authenticate - Basic realm = "your domain" which will force your browser into basic auth.

Thought 3: Spnego Negotiate in Spring Security Kerberos

The Spnego configuration in the Spring Security Kerberos documentation is acutally build upon those thoughts. This can be seen in the samples, too, in line 49 and 50 of this WebSecurityConfig.java

I would be surprised if you experience troubles.

One last thought

If no requirements force you to do a basic auth, I would recommend to not use it. Better stay with a token based authentication. Even if I don't fully agree on all details of this blog it explains why basic auth shouldn't be used, if you can avoid it.

Answer 2

I strongly recommend you read Mika's answer. It is very well done and gave me the confidence to move forward.

Ultimately this worked; but I will explain a couple sticking points I had.

I use Request matcher's to split my calls into different HTTP configuration blocks

In order 1 I configured a block to filter in requests from a specific tool, by user agent. In that block I configured basic authentication in basically the standard OOTB way. I did write and provide my own authentication provider though, this provider called to an underlying system we use to manager our users by username / password.

Then, in order 2, I configured a block to process Kerberos. After wrestling with the Kerberos provider configuration and coming up with a scheme to authenticate in our underlying system, this all processed fine. After getting the username from Kerberos for the domain user connected to my web app, I then checked to see if that username was in my system. If they are, we log them in. If not, we direct them to the login page. (Not every domain user is authorized for our web app, even if they are authenticated)

Then finally, the last block was configured for form authentication.

But there were a few sticking points.

• I had to globally configure the authentication manager for both my custom basic/form and the Kerberos provider.
• And also as a side note, I did have to configure my authentication manager bean like this link suggests. Probably due to the cobbled together shamble of of xml/java configuration I have created.
• IE was also weird. Down my kerberos chain, I also configured a login form. This allowed users who qualified for the chain to navigate directly to the login form to authenticate; or if someone failed my Kerberos username check I could forward them to the login page. This worked fine with FireFox, but IE continues to send the Negotiate header even after my server sent a redirect. Basically the user fails kerberos, gets a redirect to the login page, but IE sends the Kerberos token along still. This causes the SpnegoAuthenticationProcessingFilter from Spring Security to fire again and validate the Kerberos token, of course this fails again, and sends the user the login page which continues the loop.

In summary Spring Security allowed for 3 nice, fairly clean blocks which all do various different authentication / authorization, and then it all works in tandem to provide the same user context object to our web app.