5

I am currently trying to implement a single sign on solution across multiple JVM based (Grails, Servlets) web applications currently all deployed in the same servlet container (currently Tomcat, but don't want to limit my solution to just Tomcat). All web applications share a common database.

I've looked at various options from using CAS or other third party libraries to creating a new web service to handle Single Sign On, but none seem to really satisfy the business. My current implementation involves creating a new jar library which has a common implementation of AuthenticationProviders, and Pre-Authentication Filters based on Spring Security.

In this approach I have multiple AuthenticationProviders (currently Active Directory, and Database) for the application to authenticate against. Upon successful authentication a row would be inserted in a session table that contains the user, an expiration time, and a token. The token would be also stored as a cookie on the user's machine and that would be used to validate they have a current session in the Pre-Authentication Filters.

Having never done this before I want to make sure I'm not creating a huge security problem, and I'd also like to know what I would need to create the token? At this point a simple GUID seems to be sufficent?

Currently we are working on Spring Security 3.0.x, and haven't upgraded to 3.1 yet.

Thanks in advance.

Patrick McDaniel
  • 1,073
  • 4
  • 11
  • 28
  • 2
    I would say yes to the guid being a sufficient session id. As to security issues what are your concerns? – Rob Kielty Oct 23 '12 at 12:32
  • My concerns would be any common attacks, for instance session spoofing, that I may not be able to handle. In the session spoofing case it could be done by coping the cookie from the user's machine to another, but I believe by setting the timeout time to a reasonable level this attack is mitigated. – Patrick McDaniel Oct 23 '12 at 12:55
  • A good source for web app security pitfalls would be https://www.owasp.org/index.php/Main_Page – Rob Kielty Oct 23 '12 at 13:16
  • 1
    True, just deleted the answer. – ElderMael Oct 23 '12 at 16:49

2 Answers2

3

I ended up solving this problem by doing the following:

I created a AuthenticationSuccessHandler which would add a cookie to the user's session which had identifying information as well as the hostname to try to secure it as much as possible. (The application was running internally at most customer sites so the risks here were determined to be minimal, but be careful about cookie jacking.)

Then on each application that needed to have SSO I implemented a AbstractPreAuthenticatedProcessingFilter, and placed in before the authentication filter which would pull the cookie out and create an Authentication object. Lastly I created an AuthenticationProvider which validated the information from the cookie.

Hopefully that helps someone else in the future for this type of request.

Patrick McDaniel
  • 1,073
  • 4
  • 11
  • 28
2

There are extensions available for KERBEROS, OAuth and SAML available on the Spring Security Extensions website. Here is the blog entry which provides an example: SpringSource Blog

If you are using NTLM as your SSO Provider, take a look at the jespa-spring project.

Or you might want to look at the Java Open Single Sign-On Project

dube
  • 4,898
  • 2
  • 23
  • 41
  • This also doesn't satisfy my requirement since it involves setting up additional servers to be the authority. I have multiple applications which I want to share authentication, but don't want to require any additional servers outside of my application. – Patrick McDaniel May 21 '13 at 15:15