We are upgrading the Apereo CAS servers at UC Berkeley from version 3.5.x to 4.1.4 with some additional features deployed with the help of Unicon, one of the major contributors to the CAS project.
Features for the 4.1.x release and for our local CAS Server deployment:
- ticket caching system based on Hazelcast
- embedded CAS Protocol Security Filter
- delegated authentication
- service access control
- attribute release using either CAS SAML1.1 or CAS 3.0 protocols
- support for SPAs
Some additional existing and future features for the UC Berkeley CAS release:
- support for service redirection on logout (using the service= parameter; see below) and optional per-service logout support.
- future support for multi-factor authentication (MFA) to replace the CalNetKey second-level CAS system. MFA using Duo Security CAS 4.x integration is under development.
- support for coarse-grained authorization enforcement via integration with CalGroups (Grouper) groups and the new berkeleyEduIsMemberOf attribute in LDAP.
Currently we have the QA tier running the updated versions. The QA testing environment consists of the nodes cas-t1/t2 serviced by the virtual IP (VIP) for the auth-test.berkeley.edu DNS name. The previous cluster nodes (ncas-t1/t2) will remain available for a short transition period as individual nodes.
The production environment consists initially of the nodes cas-p2/p3/p7 serviced by the VIP for the auth2.berkeley.edu DNS name and will be running in parallel to the existing auth.berkeley.edu cluster (see the Timeline below).
For the current SSL/TLS certificates, see the CAS SSL certificates page. We have obtained Comodo/InCommon EV certs for the new auth/auth2 clusters as part of this update.
Using the redirection on logout feature
Following logout, to redirect the browser to a landing page of your choice (and which is not protected by CAS), use something like this example for the logout call in your CAS client application:
Notify your users
As part of a spoofing-awareness campaign it would be helpful for application owners to publicize the trusted CAS URLs and train CAS customers to look for the EV certificate.
CAS URLs for UC Berkeley
For UC Berkeley-affiliated web sites, during CAS authentication, you may see in your browser auth.berkeley.edu or auth2.berkeley.edu as part of the authentic and trusted web address (URL). For your safety, please trust no other unverified URLs with your CalNet credentials! In addition, look for the EV certificate as further evidence that this is not a spoofed web site.
|now until March 2, 2016||validation of CAS client applications||Test applications against the auth-test.b.e server; optionally migrate them to the auth2.berkeley.edu cluster|
|After March 2, 2016||monitor CAS client applications||The name auth.berkeley.edu points to the auth2 cluster. CAS client applications that cache IP adddresses (typically Java-based applications), may need to be restarted to pick up the DNS change. Troubleshoot any issues with your application. Clear stale cache, cookies, and bookmarks from browsers.|
Known Issues and workarounds
- No proxy authentication by default:
Note that by default, proxy authentication is disallowed for all CAS applications. Please test and let us know if this needs to be enabled for your application URL.
We welcome reports of any new issues and workarounds that folks are willing to share.
General discussion of CAS client application issues happens on the calnet-developers campus email list so all can benefit. The CAS project also has community and developer discussion lists. Send other questions and requests for testing and migration of your individual CASified application to the address found in the Help menu under CalNet Developer Support.