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!

Configuring CAS to use X.509 Client Certificates

If you run a web server (or similar device) that has protected realms meant to be restricted to Case persons, and the only authorization component you have on it is require valid-user (or similar), you should change it. In the near future, it is going to be increasingly likely that more and more persons with only a passing association with the University will be able to login i.e. they will have Case credentials and they may not be a Case employee, student, or alum. People who are using authorization that is in the style of require valid-user and are expecting their service to only be available to Case users are going to have an unwelcome surprise when someone else authenticates and gets in. (At which point, they will undoubtable blame ITS for the security hole and an op-ed will appear in the Observer about how we are not security conscious.) The best way to handle authentication in your web app is to use CAS. The best way to handle authorization in your web app is (for Apache, at least) to use mod_auth_ldap. In the scenario where you want active Case users to be able to access your protected realm, you don't do a require valid-user; rather, you:

require group students

require group employees

I'm not sure what the best way to disseminate this message about " require valid-user considered harmful." A post to ITS homepage, maybe? Have someone bring it up at the next CTO's meeting? Probably the latter. But the information needs to get out there before someone running a service has something unexpected happen.

Hopefully by now you are acquainted with the university's single sign-on service, CAS. You appreciate how much easier it makes your day. You get to work in the morning, sign on, and don't worry about specifying your password again and again and again. Well, that isn't accurate. There are still numerous services that haven't been converted to CAS. Some are for political reasons. Some are for technical reasons. Although ITS has internally tested CAS with the portal, webmail, the web Oracle calendar, and even Blackboard, these services haven't been converted chiefly because the current CAS server won't let users with passwords older than September 1999 log in. The next version of the CAS service (which is due for deployment any day now) corrects this issue. It also looks branded and even allows special users defined in LDAP to log in. For service deployers, this should be enough to convince you to convert your service. If not, you will pay dearly come February 15. The upgraded CAS service features something no other current login method at Case will: friendly integration with the new password policies. When your password expires, your account is disabled. You will not be able to log in from anywhere. The only thing you can do with your old password is use it to change your password. However, when you log in to CAS with your expired password, CAS will say "Your password has expired. Please use the Password Change Page to change your password." SITES NOT USING CAS WILL NOT BE ABLE TO DISTINGUISH BETWEEN A BAD PASSWORD AND AN EXPIRED ONE. Users will visit these non-CASified sites and enter their password over and over, confident it is correct. Frustration builds up. These services aren't programmed to check for an expired account. They just check whether the password works, which the password policies dictate it won't. People will get upset they can't use your service. They have no idea why. They file trouble tickets with the Help Desk. They call you. They e-mail you. Loss of productivity ensues. CAS exists for user convenience and for peace-of-mind with information security. I HATE typing in my password to access a site. After all, that password is available to that site to do what they want. There is nothing stopping a web site operator from putting up a site that requires my password, then takes that password and logs in to the the e-mail server as myself and downloads all my mail. They can bind to the LDAP as me and obtain my personal information. They can log in to other services as me. Your Case ID password should be yours and yours only. You should only need as few times as possible. CAS makes that possible. For all the system administrators out there who haven't deployed CAS yet, I implore you to do so. You will be conveniencing the users of your services as well as securing some peace-of-mind come February 15.

Hopefully by now you are acquainted with the university's single sign-on service, CAS. You appreciate how much easier it makes your day. You get to work in the morning, sign on, and don't worry about specifying your password again and again and again. Well, that isn't accurate. There are still numerous services that haven't been converted to CAS. Some are for political reasons. Some are for technical reasons. Although ITS has internally tested CAS with the portal, webmail, the web Oracle calendar, and even Blackboard, these services haven't been converted chiefly because the current CAS server won't let users with passwords older than September 1999 log in. The next version of the CAS service (which is due for deployment any day now) corrects this issue. It also looks branded and even allows special users defined in LDAP to log in. For service deployers, this should be enough to convince you to convert your service. If not, you will pay dearly come February 15. The upgraded CAS service features something no other current login method at Case will: friendly integration with the new password policies. When your password expires, your account is disabled. You will not be able to log in from anywhere. The only thing you can do with your old password is use it to change your password. However, when you log in to CAS with your expired password, CAS will say "Your password has expired. Please use the Password Change Page to change your password." SITES NOT USING CAS WILL NOT BE ABLE TO DISTINGUISH BETWEEN A BAD PASSWORD AND AN EXPIRED ONE. Users will visit these non-CASified sites and enter their password over and over, confident it is correct. Frustration builds up. These services aren't programmed to check for an expired account. They just check whether the password works, which the password policies dictate it won't. People will get upset they can't use your service. They have no idea why. They file trouble tickets with the Help Desk. They call you. They e-mail you. Loss of productivity ensues. CAS exists for user convenience and for peace-of-mind with information security. I HATE typing in my password to access a site. After all, that password is available to that site to do what they want. There is nothing stopping a web site operator from putting up a site that requires my password, then takes that password and logs in to the the e-mail server as myself and downloads all my mail. They can bind to the LDAP as me and obtain my personal information. They can log in to other services as me. Your Case ID password should be yours and yours only. You should only need as few times as possible. CAS makes that possible. For all the system administrators out there who haven't deployed CAS yet, I implore you to do so. You will be conveniencing the users of your services as well as securing some peace-of-mind come February 15.

After completing my chemical dependence on syndicated feeds this summer, I have grown accustomed to reading all of my news without surfing to any web sites. My news aggregator simply grabs everything and displays it for me. This fall, every one of my classes uses Blackboard, and every single course on Blackboard is updated frequently. It kills me to have to log in to Blackboard (which still requires my username and password (Blackboard can work with CAS)) to get recent announcements for my courses. So, where is the RSS? OK, so Blackboard doesn't have RSS support. Let's edit the source code. Oh wait, it is closed source.

CASifying Blackboard

From Case PAM Module

The Yale CAS client distribution includes a PAM module suitable for CAS-authenticating, say, an IMAP server.

Cooooool!