There is a CAS server written in ruby google RubyCAS. I can't vouch for it or anything but I know it exists. Otherwise there is sibboleth which seems like a pretty robust solution.
One other option you have Kerberos + LDAP. You can authenticate via Kerberos and authorize via LDAP. You can configure apache to use kerberos so it's minimal work on your app. The app then pulls information about the user from LDAP. I remember a while ago somebody on this list implemented a SAML server in ruby for a client but I have no idea if that code is available and if so under what license. Please keep us (or me if the group is not interested) updated. I am keenly interested in this subject. Cheers. On Mon, Nov 19, 2012 at 4:57 PM, Clifford Heath <[email protected]> wrote: > Folk, > > A client needs to augment an existing Rails 2 app with some additional > subsystems > that will be written in Rails 3. The goal is to support seamless SSO across > the old > and new, and to achieve a single URL address space (one domain). The latter > need > can be met using a front-end haproxy or a Rack reverse proxy to forward URLs > to > the appropriate server, so each instance of the combined app appears to run > under > one domain. > > The existing user model has a pretty straightforward authentication model, > and it > will remain the owner of the subscription and login process. So it will serve > authentication for the other subsystems. > > The method I'm proposing is a bit simpler than generalised CAS and SSO, which > I > think we can get away with because we can use shared secrets. Nevertheless I'd > like your thoughts on possible failure modes or reasons why we shouldn't do > this :). > > Assume that the user is logged-in to the legacy app already, and follows a > link to > the new app, which finds they're not already authenticated. It sends a > redirect to > the main app with a request-id encoded in the query. The main app verifies > that the > user is logged in and is authorised to use the new service, and constructs a > ticket > to send back via a redirect. The ticket contains the checksum (SHA-1 or > whatever) of: > * a shared secret > * the current time, rounded to the nearest five minutes > * the domain being served (the same server may serve users from multiple > domains) > * the user's name > This ticket also contains the user name and domain in plain text. > > The new app takes its current time and rounds it down *and* up (two values) > and > tries to match the same checksum with either. If successful, it sets its own > cookie > and the user is now logged in. The time rounding allows for delays and for > server > clock skew. > > To handle logout, the legacy app has added to the users's session the fact > that > they attempted login to the new app. When logout occurs, it must force a > logout > there before logging the user out. So it redirects the user to each > subordinate > app's logout page, which redirects back to its logout page. When the last > sub-app > is logged out, the legacy logout occurs. > > Your thoughts? How have you implemented this? What existing gems do it? > > Clifford Heath, Data Constellation, http://dataconstellation.com > Agile Information Management and Design > Skype: cjheath, Ph: (+61/0)401-533-540 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
