Blog from October, 2018

A student's home campus is in the uhScopedHomeOrg attribute returned by CAS and LDAP. We have recently discovered some issues in our calculation of the home campus, and they will be addressed on 10/30/2018.

These issues only affect the student home campus coming from Banner (dataOrigin=sis); they do not affect affect the home org coming from PeopleSoft (dataOrigin=hris):

Issue #1: was ignoring predetermined home campus change for future terms

A student's home campus in uhScopedHomeOrg was updated only when that student's academic profile data changed in Banner.  This was incomplete because such Banner data could include a range of semesters in the future that specified a different home campus.  In such cases, Banner data may not change, but the home campus might change with the passage of time, as we transition from one semester to another.

There are about 1500 students whose home campus will be changed in uhScopedHomeOrg because of this issue.

Issue #2: some returning students may be missing their home campus data

People who cease to be students lose their home campus in uhScopedHomeOrg. If they return as students, their home campus is restored only if there is an accompanying change to their Banner academic profile data. Apparently, there are valid scenarios where students return without an update to their academic profile records, so from now on, we will always retrieve the most recent academic profile after any student affiliation change.

There are about 550 student home campus values to be added to uhScopedHomeOrg because of this issue.

Issue #3: some inconsistencies between student affiliations and student home campus

It doesn't make sense to have a person with a home campus if that person doesn't have a student affiliation.  It is also unusual for a person to have a student affiliation but not have a home campus.  

These inconsistencies occurred because our calculation of the home campus did not take into account our own algorithm for calculating the applicant/student role.   Further compounding the issue is the fact that calculating the student role from Banner is complicated (see UH Role Assignments and Transitions).  In a nutshell, we aren't able to use Banner to conclusively determine that a person has ceased to be a student. Therefore, we allow people to retain their student roles if they've registered for a course during the preceding Fall or Spring semester.  This basically means that students who have left can retain their student affiliations and their home campus attributes for one extra semester.

To be consistent with our student affiliation computation, the Banner academic profile data that we use to calculate the home campus should therefore not be older than the prior Fall or Spring semester.  At the other end of the spectrum, if a student does not have a home campus applicable for the current semester, we will use the nearest future-term home campus.  This is not as bad as it seems.  Community college applicants are treated as students as soon as they apply, so it is perfectly fine that they have a student affiliation today, but a home campus that begins in the upcoming semester.

Similarly for applicants, it would be OK to use a home campus from Banner that is applicable for the current or for future terms but never one for a past term, even if it was for the preceding Fall or Spring semester.  Note that not all applicants have a home campus.

There are about 4400 people whose home campus will be deleted from uhScopedHomeOrg because of these inconsistencies being fixed.  The breakdown of these 4400 is approximately 3000 ohana, 700 applicants, and 700 faculty/staff.

Final thoughts

Remember that our definition of home campus may not always match your expectations.  For example, some applicants can have a home campus whereas your application may expect a home campus to be defined only for students.   We recommend that you always complement the home campus information with other requirements (for example, by also requiring a student affiliation).

Likewise, our definition of student may not match yours, especially since we let people retain their student roles for an extra semester after their departure.  As we said before, it's complicated, but it's our best approximation for a practical student role that can be used very widely.

If your application needs tighter control, such as requiring that a student be registered for the current semester, you could use uhReleasedGrouping for that.

The Shibboleth IdP environments (idp.hawaii.edu, idp-test.its.hawaii.edu) have been updated.

•  Tomcat has been updated from 8.0.50 to 8.5.34

This is a somewhat significant update for the Java Servlet Container that the IdP application runs in. The Tomcat 8.0.x track is scheduled for EOL 2018-06-30.

This version supports TLSv1.1 and TLSv1.2. Notably, TLSv1.0 was previously supported, but is not in this update.

 Some testers who've encountered handshake protocol errors following previous Tomcat upgrades have resolved the problem with the following (or equivalent) in their client configuration:

• Tomcat
  
  • -Dhttps.protocols=TLSv1,TLSv1.2,TLSv1.1

    • As long you have at least one of the supported protocols (TLSv1.2,TLSv1.1) it should work
    • TLSv1 above is Tomcat's configuration string for TLSv1.0 (ignored by this update to our Tomcat)
      
• PHP:

  • Set CURLOPT_SSLVERSION to 5 or 6 (or do not set CURLOPT_SSLVERSION)
    
    reported successful configuration change

    // curl_setopt($ch, CURLOPT_SSLVERSION, 4); // curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'TLSv1');

  • PHP documentation recommends not setting CURLOPT_SSLVERSION
    

    • Comments suggest, "CURL_SSLVERSION_TLSv1_1 (5) or CURL_SSLVERSION_TLSv1_2 (6) only work for PHP versions using curl 7.34 or newer"
• Consider deprecating TLSv1.0 in your client configurations if possible
  
  • SSL Labs on secure protocols

The following ciphers are supported as determined by SSL Labs' SSL server test:

TLS 1.2 (suites in server-preferred order)

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS 1.1 (suites in server-preferred order)

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

IAM production environments will be receiving quarterly patches, updates and security management tasks as listed below.  

Sunday, October 14, 6:00-8:00 AM

• Production CAS
  
  • OS and Java updates will be applied
  • Tomcat will be upgraded to the latest patch release of 8.5.
    • TLSv1.0 will no longer be supported.
  • This should be transparent since the service is load balanced.
    
    
• Production Shibboleth
  • OS updates will be applied.
  • This should be transparent since the service is load balanced.

Sunday, October 28, 5:30-10:00 AM

• Production Grouper (UH Groupings)
  • OS and database updates will be applied.

• Production RabbitMQ (UH Message Broker, UHIMS Events)
  
  • OS updates will be applied.
  • You will need to restart your application if it maintains a persistent connection.

• Production LDAP
  • OS and LDAP server patches will be applied.
  • This should be transparent since the service is load balanced.
  • You will need to restart your application if it maintains a persistent connection.

• Other services such as username requests, password changes, and other administrative applications which rely on our services may also be unavailable while our services are undergoing maintenance.

Quarterly patching is a necessary endeavor.  We appreciate your patience and cooperation.

If you have any questions, please send them to <its-iam-help@lists.hawaii.edu>.