Xavier,
The short answer is that once you log in to any one of your CAS-
enabled applications (lets say
http://portal.example.foo), you should
NOT have to log in again when you visit any other CAS-enabled
application (lets say
http://abc.example.foo). That's the whole point
of CAS.
When you log in the first time via
http://portal.example.foo, the CAS
server sets a cookie in your browser, so that when you visit
http://abc.example.foo and get redirected back to CAS, CAS sees the
cookie and immediately redirects you back to
http://abc.example.foo
along with a valid service ticket. The user doesn't see this
redirection, since it's negotiated by your browser behind the scenes.
That said, the "portal" pattern is a good example of the kind of thing
the proxy mechanism was designed for. We use proxying here at my
organization exactly for this purpose. The main difference is that
with proxying that whole redirection business never has to happen.
Your portal is able to dish out valid service tickets to your child
applications on behalf of your CAS server.
Now you can certainly run a portal-type system without proxying.
Proxying just makes it a bit cleaner I guess. Also, it's probably not
as hard to set up as you think. Just create an empty Rails
application, install the cas client as a plugin, configure it, and
you're done. It would of course be easier if your portal application
could act as its own proxy callback (logically that makes a lot of
sense) but unfortunately this is pretty much impossible with Rails
(because Rails is not thread-safe).
Hope that helps. Let me know if you've got any more questions.
Matt.