While at RubyX (now reInteractive) I helped write a CAS server: http://github.com/reInteractive/cassy
On 19/11/2012, at 15:20, Tim Uckun <[email protected]> wrote: > 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. > -- 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.
