

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

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)?
======
bdr
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>

------
csomar
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.

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

That is not really Single Sign On.

------
RobbieStats
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).

------
pclark
Facebook Connect

------
enki
oauth

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

    
    
      sudo gem install rubycas-server

~~~
blasdel
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?).

~~~
sho
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.

