Jeremy Smith's blog

Entry Is Labelled

CAS Sucks!

In my previous entry praising Case.TV, I inadvertently caused a long thread on the demerits of CAS, our Single Sign On System.

From the comments, a quote from Sean Maxwell (who was the designer (from the markup perspective not the UI perspective) of the Case.TV web site — the person I was looking for):

I hate CAS. Whatever CAS is doing I can do better and faster. I don't mind integrating with it, but relying on it is a bad idea in my opinion.

That's clear-cut enough.

I had actually not heard any push-back regarding CAS before. I didn't know CAS sucked. And I hate stuff that sucks (RE: previous post — I Must Be the Most Demanding User in the World). So I'd like to hear more regarding the demerits, inefficiencies, and general suckiness of CAS from others. Too slow? UI sucks? Confusing redirects? Too much work to interoperate with? Other?

As a possible counter-point to this future discussion, I did write-up The Benefits of Single Sign On, which covers "handling expired passwords", "handling disabled accounts", "increased security with two-factor login controls", "interoperability with federated identity for free" (for example, the OpenID server I integrated with CAS), etc. Things I didn't cover in that 2 year old article that are upcoming features to CAS include anti-phishing measures and security monitoring tools to detect compromised accounts.

But what I want to focus on is why CAS sucks. I'd prefer it not to suck. So any feedback is appreciated so that I can attempt to make it suck less. Thanks!

Comments

  1. gravatar

    If I were to start preferring CAS as the authentication mechanism for secure resources, I would probably need to see the following two things:


    1. A less obtrusive integration option. The LDAP servers do not require users be redirected to a single LDAP front end, and likewise for the Kerberos servers. I think the fact that I have to send users off site to a login page that looks nothing like my site is a big drawback. I had some integration ideas a while back for writing a perl module that would let you do the transaction with the CAS server in the background without the need to direct users off site, but I got the impression form the admins that this was going to violate some terms of service type stuff. Maybe you could add a variable to be passed to CAS that is a URL to a skin file that CAS would read and put the login box into? That way you could keep a consistent appearance with your site when redirecting users.

    2. More flexibility. You just cannot do everything through CAS that needs done at the moment. An example is for our PodCasting service. To secure our PodCast media I had to write an Apache module that integrated basic HTTP auth with both the LDAP servers, and our database of rosters for students. With the forced interactivity of CAS, it just was not even an option to try to use it for the authentication piece. If there were a non-interactive method for using it, then yes, I would be more inclined to do so


    I think those two items would improve the service to the point that I would feel that the benefits far outweighed any other misgivings i may have for it. Thank you for soliciting feedback.

  2. gravatar

    1) Writing any code that obtains a CAS session on behalf of a user completely defeats the two main purposes of single sign-on, convenience and credential security. There is a reason that the main CAS login page has a one-issue session ticket for posting data: it discourages people to use the service merely as an authenticator.

    2) True. You still need to perform HTTP Auth for a good handful of resources. This is where https://webservices.case.edu/authn/ and some server-side scripting come to the rescue. This webservice provides a descriptive error for failed logins, including information that a password has expired. It can also authenticate both Kerberos and LDAP accounts. The best solution is to mix and match the two of them.

    The only real improvements I could come up with are wanting to see increased usage (I want IMAP to accept CAS proxy tickets, for example). It would also be nice if you could exchange a CAS service ticket for LDAP information, for example. Actually, what I mean to say is I want a good authz and directory information component to supplement authn. The two are joined at the hip. We have authn tackled, but LDAP is too cumbersome for many to understand or work with.

  3. gravatar
    Maybe you could add a variable to be passed to CAS that is a URL to a skin file that CAS would read and put the login box into?

    That may open up CAS to a phishing vector of attack. I'll have to expound on that more in a separate blog entry, though. I tried typing it up in a comment, but it was too long and too ramble-on-y.

    To secure our PodCast media I had to write an Apache module that integrated basic HTTP auth with both the LDAP servers, and our database of rosters for students.

    I'm not entirely sure what the your requirements are, but I believe that should be entirely possible via CAS.

    For example, http://its-wiki.case.edu. That site does its authentication via CAS. But after authentication during the authorization phase, it uses mod_auth_ldap to make sure you are one of the 100 or so people actually allowed to enter it.

    Could you describe that one in a little more detail? I think that that should be easily doable with CAS for authentication and a regular authorization module (mod_auth_ldap, mod_auth_mysql, etc., etc.) to manage access.

  4. gravatar
    It would also be nice if you could exchange a CAS service ticket for LDAP information, for example.

    That is an awesome idea. That would fix the disconnect we've been having with CAS and good-practice-uid-reader accounts.

    I'm not sure how we would do it, though... But it's a great idea.

  5. gravatar

    Most PodCast readers run non-interactively over HTTP(iTunes,iPodder,etc...If someone knows of one that does not, let me know). To do an authenticated RSS feed, you have to use Basic HTTP auth, which you cannot setup through CAS because the user has no web form to interact with.

  6. gravatar
    To do an authenticated RSS feed, you have to use Basic HTTP auth

    Yes, that is true. That is actually something I've wanted out of mod_cas. The ability for it to pass authentication control to another layer if certain circumstances are met.

    That is, if a request comes over with the Authorization HTTP header already set, mod_cas allows this authentication to fall to another module (mod_auth_ldap, for example).

  7. gravatar

    It is possible to embed a CAS "login page" within the context of an application and still have it participate in single sign on, a la how Google Accounts works (its obviously up to deployers to expose this option).

    Other deployers have modified the login page based on the application redirecting to it (while still maintaining a common look - https://auth.vt.edu/login?service=https%3A%2F%2Fmy.vt.edu%2Fmyvt3%2Frender.userLayoutRootNode.uP)

    CAS 3.1 will also include support for SAML and returning attributes via SAML.

Post a comment