Will that create a window of time where logins always fail if you have a server time skew of more than 2.5 minutes?
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.
