Is this SSO design secure?

Question

We're working on an SSO implementation that would be used accross domains. I realize there are proven working models out there like CAS for this but I'm toying with a different approach and I want to get feedback from you all here to see if this is secure or not. The basic premise is that we don't want to use redirects if we don't have to and we want the product sites to be able to style their own login pages. This targets IE8+ and modern FF and webkit only. So, without further ado the implementation:

1. Client browses to product site A.com. They don't have a session cookie for a.com so the site initiates the parent auth script.
2. The parent script builds an iframe that loads a page from the auth server on auth.com. Auth.com validates the request based on the referer header and if the referer isnt trusted then responds with x-frame-options:DENY and/or a frame busting redirect.
3. The script on this page (the framed script) does an ajax request to auth.com's server asking for an SSO 1 time token (1TT).
4. The client doesn't have an auth.com cookie so this is rejected, and the iframe script tells the parent script to build an auth form using window.postMessage (and the parent script validates the origin) to communicate since it is cross domain.
5. The user enters their credentials, and hits submit.
6. The credentials get passed from the parent script to the framed script via postMessage again, and the framed script uses them to login to auth.com, receiving both an auth.com cookie and a 1TT.
7. The 1TT is passed back to the parent script.
8. The parent script passes the 1TT to A.com's server.
9. A.com uses the 1TT to get the user info from auth.com's server via a private internal API, and auth.com invalidates the 1TT so it can't be used again.

10. A.com returns a session cookie for A.com to the client, and now the client goes about its business on A.com.

11. Then the client browses to B.com, but again has no session cookie for B.com. The parent script is executed again, which creates an iframe again pointing to auth.com. The iframe script requests a 1TT from auth.com, and since it has a session cookie for auth.com this time it gets one.

12. The 1TT is passed from the iframe script to the parent script to B.com's server which uses it to get the user from auth.com and issue a session cookie for B.com.

My main concern is at step 2. Is this a solid way to prevent malicious framing? What other security vulnerabilities is this susceptible to?

Edit: All sites and scripts will be loaded HTTPS.

Answer 1

There's not really enough information in your list (as hard as that is to believe, with 12 steps and all) to properly answer, but as you mentioned in your comment above - this is pretty close to the StackExchange model.

With that in mind; have you considered running your own OpenID Provider? The protocol spec looks pretty close to what you're after. This is also a well-tested model, so a lot of the concerns have already been well-solved. OAuth may be suitable, but it's designed around limited access tokens - don't know enough about what you're doing to say which is more appropriate.

Coming back to your model - what you've specified looks ok, though as written there's a mix of 'model' stuff and 'implementation' stuff that makes it a bit tricky to analyse. You're relying on the referrer, but it looks like in this scenario, faking the referrer will only log a client in to a different site they would have access to anyway. You are depending on referer though - maybe just load the frame with a GET request including the referrer?

You're also relying on the ability to pass info back and forth between frames; you may want to consider using an interim page on auth.com instead (i.e. forward user to auth.com, if user already logged in there, POST back to https://B.com with 1TT). Using iframes complicates things (What if you're already in a frame? You're relying on the browser here to 'break out' successfully - could this be subverted by messing with the DOM?). You may be able to make this secure, but it's a complicating factor - and the enemy of good security tends to be overly-complicated schemes.

Answer 2

This SSO Design has a number of technical limitation that make it impossible to implement. There are security concerns with this design.

The worst vulnerability that this design implements is OWASP A9-Insufficient Transport Layer Protection. SSL must be used to protect all authentication information, therefore if you spill an authentication cookie over HTTP a session could be hijacked. So if a user on a wifi network were to authenticate using this SSO Design, they could have their account hacked with a tool like firesheep.

#2 is not possible: The originating site A.com must load the authentication iframe using an HTTPS page. However, by doing this, the referer header element will be missing and there is no way to verify where the request is originating from. Mozilla's Origin Header Proposal is trying to fix this problem, but its not supported by all browsers. OAuth uses a Signed Callback URL to insure that a browser is being authenticated to a trusted domain.

For #9, instead of sharing user data with "private internal API", try using a public standard like OAuth. In fact what you have described sounds a lot like 3-legged OAuth. OAuth is probably how you authenticated to http://security.stackexchange.com to ask this question, and it has proven to be secure.