Blog from May, 2018

The CAS test environment (cas-test.its.hawaii.edu) has been updated.

As always, we encourage you to test your applications against the updated environment.

•  Tomcat has been updated from 8.0.50 to 8.5.31

This is a somewhat significant update for the Java Servlet Container that the CAS 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 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

Barring unforeseen problems, this update will be promoted to our production environment at a date yet to be determined.

We will advise before doing so.

In a matter of weeks, expect to see a new role value for postdocs:

• staff.postdoc will appear as a new <role> value in UHIMS Events
• staff will be used for these postdocs in LDAP/CAS eduPersonAffiliation and uhOrgAffiliation
• There will be a released grouping for postdocs (name to be determined). This means you will be able to check for postdocs in LDAP/CAS uhReleasedGrouping

This does not necessarily identify all postdocs at UH

This new role allows us to better identify postdocs who come to us, usually because they can't request a username due to our not having any records about them. Prior to this role, postdocs may have been input into UHIMS with a role of faculty, staff or other.  Eventually, every postdoc that's been manually input into UHIMS should have this new postdoc role.  We will encourage those who renew postdocs to do so using this new role.

Keep in mind that this role is only used for those postdocs that reach out to us.  Some postdocs may never have this new role because they are already in PeopleSoft as a faculty researcher or as a non-compensated employee.  There may also be postdocs from RCUH, and they only get the staff role.  This is why this new role doesn't necessarily identify all postdocs at UH.

Your application should account for this new postdoc role

We have previously stated this, but let us reiterate that your application should be written in such a way that new attribute values won't break it.   You code should simply look for the values it needs to handle and ignore any other values.

The following groups have recently been added to the UH Group Store:

• hawaii.edu:store:hris:uhBargainingUnit:<BU>
• hawaii.edu:store:hris:jobCode:<Job Code>
• hawaii.edu:store:hris:functionalCode:<Functional Code>

The last two groups are very HR-specific, so they might be mostly useful for OHR applications, but I could be wrong about that.

There are wildcard groups for job codes and functional codes, and their names end with an asterisk. For example, the job code wildcard groups have two levels (wildcard after first 3 chars, wildcard after first 4 chars):

• hawaii.edu:store:hris:jobCode:011* includes
  
  • hawaii.edu:store:hris:jobCode:01147
  • hawaii.edu:store:hris:jobCode:01149
  • hawaii.edu:store:hris:jobCode:01150
  • hawaii.edu:store:hris:jobCode:01151
  • hawaii.edu:store:hris:jobCode:01159
    
    
• hawaii.edu:store:hris:jobCode:0114* includes
  • hawaii.edu:store:hris:jobCode:01147
  • hawaii.edu:store:hris:jobCode:01149

We will eventually switch all wildcard groups to use this nomenclature.