
Building and implementing a Single Sign-On solution - raganwald
http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/
======
tptacek
_The cookie doesn’t need to contain a lot of data, its value can contain the
account id, a timestamp (to know when authentication happened and a trusted
signature) and a signature. The signature is critical here since this cookie
will allow users to be automatically logged in other sites. I’d recommend the
HMAC or DSA encryptions to generate the signature. The DSA encryption, very
much like the RSA encryption is an asymmetrical encryption relying on a
public/private key. This approach offers more security than a shared secret
like HMAC does._

"Yes, definitely build custom crypto for your single signon system, especially
if you think HMAC is an "encryption" but just "not as secure" as DSA because
it's "shared secret"."

SSO schemes are one of the primary reasons people build crypto for their web
apps (they don't want the database dependency between the shared apps). These
schemes usually fail calamitously, sometimes a year or two into production,
when your app coughs up the ability for one person to log in as any other
person without a password.

If you have a real app with a real customer base or doing real revenue and
feel the need to put something like this in the field, please ping me. I'm not
going to try to charge you. I may try to talk you out of it, though. I will
_absolutely_ talk you out of using RSA or DSA.

~~~
ovi256
Thanks for the expert feedback. From my very limited sec experience, I saw
account_id in cookie, and identified that as a red flag. OTOH, I think a
random token in the cookie, identifying a server-side session that stores the
account id, would be a good approach, as it's the classical HTTP auth
implementation. For example, what the Rails tutorial describes [1].

For SSO, the other apps can ping the cookie-originating app: "Hey, who is this
browser with this cookie token" ?

[1] <http://ruby.railstutorial.org/>

~~~
tptacek
That's a fine approach, but developers push back on it because it requires all
the apps in the SSO federation to be connected at all times. Most shops should
just accept that requirement and get on with their lives, though.

------
bdunbar
This might be the right place to ask but ... is there a reason people keep
reinventing SSO?

It's 2012. The first place I saw SSO was on a Banyan VINES network, in 1990.
Years, I hasten to add, before NetWare figured it out.

We've got it, still, in the enterprise. It's now Active Directory, but I can
use my same credentials for login and auth on Windows clients, unix machines,
two different web apps from as many external providers.

Note, I have no idea how the web apps obtain my login credentials, save that
the AD guy and the web guys did some black magic behind the scenes.

Why do people keep re-inventing SSO, sometimes badly? No way to make a black
box that Just Works?

~~~
bmelton
What is the 'de facto' answer for environments where AD isn't present?

I was going to say something about AD not supporting SAML, or federation, but
it appears that my knowledge is dated. But in an enterprise where there are no
Windows machines (to my knowledge,) much less Windows servers, what's the
fill-in?

*Edited the snark out.

~~~
kprobst
A lot of enterprises use SiteMinder (aka ChannelSecure), which used to be
Netegrity's before they got bought out by CA. It supports both Apache and IIS,
although I'm not 100% sure what the policy servers run on, it might be
Windows. But I have seen LAMP apps that integrate with it, for example. It
really is just an intercept-and-forward system that functions as a module on
the web server and puts a few things on the HTTP headers to allow apps to
handle authorization by themselves.

~~~
m0nastic
After about a decade of testing people's web applications, SiteMinder has
defnitely emerged as the standard third-party tool for SSO.

Many years ago, it seemed like people were fairly evenly split between
Siteminder and another one (I think it was called GetAccess, but the fact that
I can barely remember it is probably an indication of it's current
popularity).

Siteminder is a good solution (and I've probably tested about ~150 web
applications over the years that are using it).

It's caused my attack plan to go from "Let's see how fundamentally broken this
company's home-grown SSO solution is" to "Oh good, they use Siteminder. Let's
see what areas they haven't implemented it properly in."

That's an important distinction, and the bulk of issues I've found with
Siteminder over the years have all been in identifying specific pages or
transactions which aren't properly using the SMSESSION. I found a forehead-
slapping issue recently where there was one page that wasn't properly
validating the SMSESSION (it was just checking to see that it existed). That
page happened to be the "reset password" page, and it was possible through a
series of redirects to modify anyone's password to whatever you wanted, even
if you didn't have a valid account on the system.

And that's kind of the problem, which is that even using someone else's SSO
mechanism (which, again, Siteminder is as good as any one I've seen over the
years), If you've screwed up the implementation for any transaction or on any
page, you're still screwed.

------
jondot
You might also want to examine the OpenID way, in which case you can use for
example, this <https://github.com/jondot/passage>, or this
<https://github.com/dbloete/masquerade> (depending on how complex the project
you want to build on)

------
famoreira
Would openID be a good option for a SSO solution? If so what would be the best
way to implement a openID server using Ruby?

~~~
etdebruin
Check out <https://github.com/dbloete/masquerade>

I haven't used it.

