CAS flow: am I missing something?

247 views
Skip to first unread message

Xavier Defrang

unread,
Jan 25, 2008, 8:38:42 AM1/25/08
to RubyCAS

Sorry if this post sound a little stupid but I've been struggling with
CAS related problems for a a few days and I think that my vision is
now impaired by all my trial/error experiments.

From the rubycas-client README:

<snip>
When a user logs on to your CAS-enabled website, the CAS client checks
with the CAS server to see if the user has been centrally
authenticated. If not, the user is redirected to your CAS server's web-
based login page where they enter their credentials, and upon
successful authentication are redirected back to your client web
application. If the user has been previously authenticated with the
CAS server (with their "ticket" being held as a session cookie), they
are transparently allowed to go about their business.
</snip>

Does that mean that if I'm CAS authenticated but that the CAS-enabled
website I'm visiting has no ticket in request parameters or session
yet, the user will be redirected to the authentication server?
I admit I didn't read the CAS specs cover to cover but looking at the
code in the CAS::Filter plugin it seems to be the actual behavior.

I'm currently building a moderately complex Rails-based Portal system
which has a number applications running on various subdomains and once
authenticated, a user must be able to use any other applications
without seeing a login form anymore.

In this context I'm trying to minimize as much as possible the amount
of functionality required to make the app portal-enabled so I don't
want to go down the CAS proxy ticketing slope which really sound a bit
too complex than it should in term of implementation and runtime
maintenance. The system I'm dealing with at the moment is already
complex enough on its own so I really want to keep the SSO layer as
simple and unintrusive as possible...

Can anyone enlighten me about my above assumption about CAS?
What can be done to make sure this SSO works for all apps, even if no
ticket is present yet?
Is there any way another application can bootstrap another's
authentication status by providing it with a ticket or something
similar?

Cheers,

Xavier

Matt Zukowski

unread,
Jan 25, 2008, 10:13:11 AM1/25/08
to RubyCAS
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.

Xavier Defrang

unread,
Jan 25, 2008, 11:27:36 AM1/25/08
to RubyCAS

Thanks a lot for your reply Matt,

I finally found the problem: I've had to do some changes in the CAS
client plugin to implement some client request regarding redirections
to the standard login form... no wonder I had some long forgotten,
missing piece in my mental puzzle. And as I wrote earlier, I ended up
blinded by the long hours of troubleshooting, now I've seen the light!

Cheers,
Reply all
Reply to author
Forward
0 new messages