Well known modifications to baseline CAS 2.x:
Services whitelist
High level discussion
An important feature of CAS is its openness. Bring up a CAS instance at your institution and you can let application developers of varying trustworthiness and ability produce applications against which your users securely authenticate. Passwords are not exposed to these potentially suspect applications. There's a lot to be said for not having to centrally manage the set of applications authorized to use your central authentication server.
However, some institutions nonetheless want to restrict the set of applications able to authenticate using CAS. This is typically implemented as a whitelist of services. Service tickets will only be vended for whitelisted services.
Feature specification
CAS administrators can specify a whitelist of services. CAS will only vend tickets for these services. It is easy to implement compelling user factors / UI for the case where the service is not authorized for ticket vending.
Implementation notes
This can be implemented under CAS 2.x as a Filter which examines the "service" parameter of the login / proxy request and forwards to an error page if the service is not authorized. A similar implementation may be very possible under CAS 3.0. That is, this feature may not require any changes or accomodations by the CAS server product itself.
Who has done this
Columbia University has done this. So has University of Delaware.
Single Sign Out
High level discussion
Some CAS adoptors, notably the Campus Crusade for Christ, have added a Single Sign Out feature whereby CAS Server calls back client applications for which it validated tickets during the CAS session when the user explicitly logs out of CAS.
Feature specification
This feature might best be specified as a well-defined but optional extension to the CAS protocol. At ticket validation time, the CAS client can specify the URL whereat it would like to be called back with the ticket it is validating, indicating that the user has logged out of CAS. If the CAS server supports the feature, the validation response would include confirmation of the registered logout callback URL. CAS clients not supporting the feature will not specify a logout callback and so will receive an unmodified validation response. CAS clients supporting the protocol interacting with CAS servers which do not support the protocl will not receive callback confirmation in the validation response and so will not expect the logout callback. Clients will have to be prepared to deal with the callback not happening anyway since this affirmative callback might be blocked by network difficulties, etc. CAS clients supporting the protocol interacting with CAS servers supporting the protocol will receive confirmation in the validation response indicating that they can expect the server to attempt the callback. Again, the callback could fail due to network problems, the client application being out of service at the time of the callback, etc.
Audit Trail
Who has done this
Cal Poly).