On 03/12/2012, at 5:33 PM, Daniel <[email protected]> wrote: > Will that create a window of time where logins always fail if you have a > server time skew of more than 2.5 minutes?
Yes, exactly. That's intentional, and tuneable. It's also basically what Windows Kerberos AP implementation uses in domain logon (I think they allow a five minute skew either way though). It seems to work... Clifford Heath. > On Monday, November 19, 2012 2:57:53 PM UTC+11, Clifford Heath 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 view this discussion on the web visit > https://groups.google.com/d/msg/rails-oceania/-/ZviK2oRCC1gJ. > 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.
