Dynamically setting service_url on ticket request makes tickets unvalidateable

[Aeon]

Currently rack-cas sends the user's request path as 'service_url'. The service_url however is used as the unique identifier for the service on the authenticating server side.

So if the request is with service_url mysite.com/users/profile, the ticket that is issued is not going to be considered a valid ticket for mysite.com/history or any other path on the site other than /users/profile.

As far as I can tell, this issue is masked by the fact that a lot of people (myself included) load the user info from session, and consider the user authorized as long as session['cas'] is set, without actually validating the user ticket. I don't see any automatic call to 'validation' in rack-cas gem.

I don't see anything in the CAS specification that describes decoupling service_url from return url that user should be redirected to - I think this is a failure in the spec. I submitted patches to rubycas-server and rack-cas-client to use an additional 'from' parameter that would hold the service path that would be combined with the service_url to generate the user return url for redirection.

I can submit a similar patch to your project if you agree that this is a good solution to the problem.

[adamcrown]

I'm a little hesitant to tack on functionality not defined in the CAS spec. But if you can get support into CAS servers like rubycas-server, I'd be happy to support it. You may also want to look at casino. It's becoming a popular Ruby CAS server.

If I'm understanding you right, you're talking about authenticating every request to your app against CAS instead of authenticating the first request and storing that authentication in the session. This is possible, but generally not recommended because of performance issues and the fact that the redirecting is going to mess with your POST requests. Just something to keep in mind.

[Aeon]

I actually do have a pull request open to rubycas/rubycas-server#232

My patch does not require user to re-authenticate on every request; it merely makes it possible to decouple the service url from return url. Right now there's only two options in how people are using CAS:

1. Always use the site root url as service_url
   • pro - the user session ticket is always "valid" no matter what page on the site they hit
   • con - if the user is not logged in, they are always redirected to site root after login.
2. Pass whatever url user has hit on page load as service_url (what rack-cas does now)
   • pro - the user is redirected correctly to wherever they came from
   • con - the user session ticket is not "valid" according to CAS whenever they hit a different url on the site, so the user would have to re-login as soon as he hits a different section on the site.
   • this is currently not happening with rack-cas gem because it doesn't actually validate the user session as far as I can tell, it just checks that it exists.
   • if you compare with rack-cas-client gem, that one does validate the ticket on each request.
   • as far as I can tell from the CAS spec, according to the protocol the site is supposed to validate the user ticket on request by hitting /serviceValidate CAS server endpoint - not just assume that the ticket is valid as long as it exists in the session.

With my patch, you get both tickets that pass /serviceValidate check, and redirection to an arbitrary page within the site. It is also not a breaking patch - if the server does not support the new parameter, it will ignore it, and the user will be redirected back to service_url just like before.