Skip to content

System/Architecture Overview

Components

This document was created to reflect the environment in use at New Paltz for CAS.

If you want to use another version of CAS 6.x - it may or may not have significant changes. I started with CAS 6.2 for these documents and our own install, but ran into issues with the Duo MFA module, so moved to 6.3.

If you are going to use another operating system, web server, or java servlet container, I'd imagine the CAS portion of the instructions will be relatively similar - though the Ansible deployments for Tomcat may be less similar or useful.

Design

We have three levels of CAS here at New Paltz, Production, Test, and Development. Test is used for non-production applications that still need SSO (for example Banner test). Development is exclusively used for building, and testing, new versions or configuration changes for CAS.

Authentication will be against either:

  • On-prem Active Directory (for alumni)
  • Azure Active Directory (for active faculty/staff/students, and retirees)
    • Note: we may eventually have all alumni in Azure - still working on that.

In each case - the hosts sit behind a load balancer (in our case, F5 Big IP, though HA Proxy or basically any other load balancer should work. We're not doing anything crazy at the LB level).

The load balancer is split in multiple locations, as are the application servers. This gives us resilience if a single site on-campus is down but does NOT give resilience against a full outage on-campus. This is one reason why we are looking to have as many services as possible authenticate directly against Azure instead of CAS.

Using CAS to delegate authentication to Azure, we can:

  • make this transition as streamlined as possible (and avoiding the need for people to have to login twice through two separate SSO systems)
  • will let us make the transition of existing CAS apps to SAML on Azure (if they support SAML) gradual, so we don't have to change 30 services (involving both internal and external service providers) over a weekend.
  • and will let us keep applications that only support CAS on CAS.
  • centralize logins for almost all college systems in a single place making incident response, and troubleshooting, easier.

Limitations:

  • Any application still authenticating against CAS will still have CAS as a point of failure. You can reduce this by having CAS load balanced and in multiple sites (on-prem, off-site, in the cloud, etc.).
  • Since Azure will see CAS as a single application, you are left to either:
    • exclude CAS from Azure conditional access policies and use CAS to implement MFA
    • include CAS from Azure conditional access policies but there are no 'exceptions' (i.e. that one service that really doesn't do anything sensitive or important and you don't want to turn MFA on for will still have it)

Rationale

Azure itself hasn't been the most reliable service at times. The total 'downtime' for Azure authentication has been far higher than our on-prem environment - but even so I have confidence in it. If it breaks - Microsoft folks will fix it - usually pretty quickly.

On the other hand - I've learned over the year that CAS is complex. I can train people here on it - but if I'm unavailable or we have issues which others cannot solve - we have issues. If you're in a similar boat, you may want to do what we're doing. You may also want to look at other companies like Unicon who can provide technical support and assistance as a service for CAS and other open source products.

We will have outages on-prem (or even in the cloud if we just run CAS and AD in the cloud). Over time - reliability will strongly favor a large service like Azure over what I personally can setup.