Client Security Recommendations

Owned by ScottS
Last updated: Oct 24, 2011 by Jennifer C. SmithVersion comment
1 min read

This is a living document. We encourage you to contribute your best practices to it.

Please see the announcement about mitigating the risk involved with some of the inherent characteristics of bearer tokens.

This page details CAS Client, and general secure application development best practices. We encourage you to reference these, along with those from other sources including OWASP.

Technical

  • Enable HTTPS. If HTTPS is not used, the tickets that a CAS Server sends to a CAS Client can be read in plaintext "over the wire". See Man-in-the-Middle Attack
  • Minimize applications that have access to passwords (CASify applications) - Self-serving since it means using CAS more, but the fewer applications that have access to passwords, the less chance there is an application that can compromise a password. Proxying exists to support downstream services that applications need to access.

Educational

User Experience

  • Display some unique aspect of the user on each page in order to reinforce that it is, in fact, their account that they've logged into.
  • Extremely sensitive sections should opt out of single sign on (i.e. applications that ask for or hold financial or medical information).

Other Notes of Importance

The CAS Server will be making substancial changes to the way the default CAS interface works in order to better inform the user of when they are logging into an application, and who they are logging in as. Many of these changes will go into affect in CAS Server 3.5.