Ask HN: Good architecture for web single sign-on? | Hacker News Reader

Ask HN: Good architecture for web single sign-on?

7 pointsRobbieStats11 comments

I have a network of sites (each with unique top-level domains) and I'd like to share logins across. Any suggestions to support single sign-on (I'm using Rails)?

View on HN

Have you looked at SAML? It may be too complicated for your use case, but the basic technique could be useful. http://en.wikipedia.org/wiki/SAML

Why don't you try the Open-ID login, users can log with their Google account.

If your user account isn't much used (the site is a blog site), you can do a simple FaceBook Connect or Google Friend Connect.

People would have to log in again on each domain independently, with separate login cookies for each.

That is not really Single Sign On.

Are you kidding? Facebook Connect might be OK for blog comments but for a professional site it is totally unacceptable. Since he's considering implementing SSO I would consider it a pretty serious project.

You do realise many people don't have Facebook accounts, right? And not just because they haven't heard of it?

Not one of my top 5 technically knowledgeable friends have a Facebook account.

Thanks for the suggestions, but it sounds like there still aren't good (simple) solutions for web single sign-on (where you don't have to log in to multiple sites separately).

Facebook Connect

oauth

Check out http://code.google.com/p/rubycas-server/

  sudo gem install rubycas-server

How much have you actually used CAS? http://www.jasig.org/cas

While it's pretty much the only game in town for true SSO auth, it can end up being a huge pain in the ass to integrate with existing software because of two glaring deficiencies:

1) It only tells your app the authenticated username -- not even group membership! A lot of off-the-shelf apps would require significant refactorings to allow you to integrate with LDAP for groups/info but not auth. What ends up happening at a lot of universities (where CAS is used) is that each app keeps it's own native user database for everything but passwords, and it's fucking awful. It's so unfortunate that OpenID recapitulated the same problem all over again with no improvement.

2) It's easy to grow a fuckton of redirects. I distinctly remember a problem where Safari would follow one-fewer redirect than IE/Moz, and the semi-competent technical staff had set up several apps at the limit (maybe 10?).

Oh, I haven't used it at all! It just sounded like he wanted some starting points, and no-one had mentioned it, so I thought it would be a good addition.

Hm. From point 1 - isn't that a design problem? Of course apps should not keep their own user databases .. I don't see that as necessarily a problem with CAS per se, more like people shooting themselves in the foot with the gun they're given. As you say, they're legacy apps, but still.

And point 2 - really? I would have thought a maximum of 2 - one to the CAS server, and one back! Any more details, out of interest?

Anyway, I looked at CAS and something about it didn't sit well with me, I don't even remember what, so I ended up rolling my own. Which, by the way, was not at all hard.

I'll take a look. Thanks.

Reply on news.ycombinator.com