Blog from July, 2021

CAS Single Logout (SLO) to be Disabled
Baron Fujimoto posted on Jul 21, 2021

Per the CAS Protocol, the /logout endpoint is responsible for destroying the current Single Signon (SSO) session. UH Login's CAS currently supports SLO.

However, because SLO may affect other applications using SSO[*], SLO will be disabled in future deployments of CAS.

It is currently disabled in the following CAS environment:

  • https://cas-future-test.its.hawaii.edu (currently CAS version 6.3)

When CAS is updated to 6.3 in our production environment on 2021-08-15, it will also be disabled there as well.

  • https://authn.hawaii.edu

This will be consistent with the SLO policy already in effect for our Shibboleth IdP SSO service.

[*] From the CAS documentation for Single Logout (SLO):

When a CAS session ends, it notifies each of the services that the SSO session is no longer valid, and that relying parties need to invalidate their own session. Remember that the callback submitted to each CAS-protected application is a notification; nothing more. It is the responsibility of the application to intercept that notification and properly destroy the user authentication session, either manually, via a specific endpoint or more commonly via a CAS client library that supports SLO.

Also note that since SLO is a global event, all applications that have an authentication record with CAS will by default be contacted, and this may disrupt user experience negatively if those applications are individually distinct from each other. As an example, if a user has logged into a portal application and an email application, logging out of one through SLO will also destroy the user session in the other which could mean data loss if the application is not carefully managing its session and user activity

CAS test environment updates 2021-07-21
Baron Fujimoto posted on Jul 19, 2021

Updates were applied to following IAM test environment the morning of 2021-07-21:

CAS: cas-test.its.hawaii.edu

  • Tomcat update from 8.5.63 to 8.5.69
  • Java update from 1.8.0_271 to 1.8.0_291
  • The service will be migrated from RHEL 6 to RHEL 7
  • TLS termination will be handled by the service cluster's load balancer
    • one consequence of this is that we will lose TLSv1.3 support until the LB can support this protocol - TLSv1.2 will be the only version supported for now)

(warning) Unusually, these specific updates will not be promoted to our production environment at a later date.

Instead, the configuration currently deployed in our cas-future-test.its.hawaii.edu environment with the upgrade from CAS 5.0 to CAS 6.3 will be the next major update to our production CAS environment on 2021-08-15

References:

UH Login to feature an updated user experience
mhodges posted on Jul 09, 2021

Overview

UH Login will be upgraded to the latest version of the Apereo CAS software.  With this upgrade we are simplifying our UI customizations while also ensuring that the user experience remains familiar.  The increased efficiency in deploying new versions of CAS software will become very important as we move towards a faster CAS software upgrade cadence.  We anticipate multiple upgrades annually and new procedures to support this cadence.  The faster cadence is needed to ensure the security of our UH Login services.

Schedule:

  • New 6.3 Test environment: Monday, July 12, 2021
  • Production environment: Sunday, August 15, 6:45 AM, 2021

Preview

The current UH Login experience vs the new UH Login experience:

Summary of the UI Changes

Technical changes

  • CAS 6.3 implements Twitter Bootstrap (not new, but previously ignored by the UH Login customizations) and Material Design Components.
  • CAS 6.3 utilizes the Maven WAR Overlays.  These make it easier to upgrade CAS while preserving the UH Login UI changes.  
  • CAS 6.3 changes are implemented with minimal coding changes, as minimal as possible while ensuring a high degree of familiarity to our community.

Visual changes

The CAS 6.3 out-of-the-box presentation has evolved such that it is not much different from what we've implemented in UH Login already.

The changed elements:

  • The username and pwd input boxes.  These are rendered
    • without the leading input text icons,
    • using UH colors for the boarders and filler text, and
    • using the filler text preservation feature to remind the user of what is being entered while typing.
  • Pwd input box is rendered
    • [updated 09/29/2021] using the default CAS make-visible feature, which can't be left visible since it is only visible while being pressed (a minor security enhancement).
    • Due to ADA issues later discovered with the new implementation, we have reverted back to the original show/hide toggle implementation.  We have also notified the team that maintains the CAS open source project of the ADA issue.
  • Login button
    • Login is spelled as a single word, the default CAS spelling.
  • UH Logo
    • Slightly smaller in order to fit the Bootstrap layout and to reduce the need for further modifications.
  • Copyright
    • Updated to 2021.
  • Responsive design changes
    • The Forgot Password link is not converted to a button on small screens.

References

CAS 6.3 Upgrade plans for Summer 2021
mhodges posted on Jul 09, 2021

Overview

CAS will be upgraded from version 5.0 to version 6.3, the latest support version. The upgrade is required in order to better ensure that we can apply security patches and bug fixes and will allow us to implement new features as they are needed, such as asserting the REFEDS MFA attribute to service providers such as the Nation Institute of Health, which will be of importance to our research community.

Schedule:

  • New 6.3 Test environment availability: Monday, July 12, 2021
  • Production environment upgrade: Sunday, August 15, 2021 starting at 6:45 AM and concluding by 7:45 AM

Blog update for 8/9/2021:

What you need to do

Test early!  Verify that your application can successfully authenticate.

While we do not anticipate any issues, testing is highly recommended so that you can assure yourself that the CAS 6.3 upgrade will not adversely impact your community.  One caveat, see Known Issue #1 below.  If your application is meant to ignore SSO (to require authentication each time) and does not request LDAP attributes, be sure to test your application to ensure that it is configured consistently.

Please keep in mind that there are now two CAS Test environments:

It is recommended that you maintain a test environment for testing your application at all times. Creating one can be time consuming, which should be factored into your planning. In the future, upgrades to UH Login will become more frequent, making the ability to easily test all the more critical.

What does success look like?

  • A successful authentication to your application indicates success.

The best strategy for testing:

  • Point your application test environment to the new CAS 6.3 test environment and ensure that you are able to authentication successfully and access and process any expected attributes that are returned.

A strategy to consider if there is no test environment:

  1. Designate a maintenance window for your application and coordinate with your community.
  2. Ensure that you have UH accounts that work in the UH Login test environment (see below).
  3. During the outage configure your application to point to the new test CAS 6.3.
  4. Rinse and repeat until you have tested successfully.
  5. Create a repeatable procedure, this is going to become regular activity.

Additional information

The User Interface has been updated:

If you provide IT support, please note that there are minor changes to the IU.  If you have created documentation that includes a screenshot of UH Login, you may want to update the screenshot.  The following blog provides details:

Where to get help

If you encounter issues while testing, the IAM team and the UH App Developer community participate in a community emailing list.  Please post your questions there since others will likely benefit from the discussion:

If your password is not working in the test environment, contact the IAM team to request a password sync:

Known Issues

Issue #1

Issue Summary:

  • If an application does not apply the renew=true option for the login action, but does apply it for the validation action, the user may not be required to re-authenticate.

Issue Details:

  • If the application does not use renew=true for /login, but subsequently uses renew=true for either /validate or /serviceValidate, the user may use an existing SSO session and will not be forced to re-authenticate.
    • Example usage that triggers bug
      • https://cas.example.edu/cas/login?service=https://www.example.com/app
        https://cas.example.edu/cas/validate?service=https://www.example.com/app&ticket=ST-...-cas&renew=true
  • This bug does not occur for the /samlValidate option used to obtain LDAP attributes.
  • This is a known issue with CAS 6.3.5 that was originally detected with the IAM team's regression testing suite for CAS. CAS 6.3.5 is the most current release of CAS.

Issue Assessment:

  • It is common for applications that access sensitive information to require LDAP attributes in order to limit access to sensitive information. The bug will not manifest for these applications.
  • This bug should rarely occur, if it all, and is easily mitigated if encountered. 

Issue Mitigation:

  • Configure the application's use of CAS consistently if requiring authentication each time, as opposed to potentially reusing an existing SSO session.  Application developers should consistently apply the renew=true for both the /login and the validation action, /validate, /serviceValidate, or /samlValidate option while you are revisiting your configuration.
    • Example usage that mitigates bug (note consistent usage of renew=true)
      • https://cas.example.edu/cas/login?service=https://www.example.com/app&renew=true
        https://cas.example.edu/cas/validate?service=https://www.example.com/app&ticket=ST-...-cas&renew=true

References