Shibboleth Upgrade

Owned by Amit Poddar (Unlicensed)
Last updated: Mar 08, 2021
4 min read

This change only applies to the applications that use SAML for authentication and uses Shibboleth Identity Provider (https://auth.yale.edu).

If an application uses CAS (https://secure.its.yale.edu/cas) for authentication/single sign-on then this does not apply.

What is Shibboleth?

Shibboleth is Yale’s Identity Provider (IDP) that supports SAML integration for single sign-on with vendor applications like Workday, Service Now etc.

What is the change?

Yale current implementation of Shibboleth is at version 3.x. This version has gone out of community support since December 2020, and to still be under support we need to upgrade to Shibboleth 4.x. This change upgrades the current Shibboleth implementation to version 4.

Is there any expected impact?

No. This is only a version upgrade without any change that a service provider would notice. We expect the upgrade to be seamless and transparent to the service providers. But with any change there is always a chance, though minuscule, that the upgrade might have some unforeseen impact.

Can we test the upgrade?

Yes, we have setup an alternate upgraded Shibboleth IdP for this purpose. But this will not be regular testing situation where you point your non-production environment to the upgraded Shibboleth IDP and test the authentication.

We opted against it due to two main reasons

  • Most vendor applications do not have a non-production environment

  • Setting up a new SAML partnership involves multiple steps, and there is a chance where we can spend lot of time debugging the new SAML partnership setup instead of focussing on the upgrade testing.

How would we test the upgrade?

SAML is a browser based protocol i.e., all actions during SAML authentication transaction is initiated by the browser, therefore, if we can trick the browser that the new upgraded Shibboleth IDP is the production IDP then testing would involve logging an SAML protected application using regular login process.

We can trick the browser by adding an entry in the local hosts file which points the production Shibboleth IDP’s DNS name (auth.yale.edu) to the IP address of the upgraded Shibboleth IDP. Please refer for details on how to update the hosts file on different operating systems.

This is the process that the IAM team has used to test logging into multiple SAML protected applications like Workday, Service Now etc.

In the next section we will walk through this testing process in detail. If you are not comfortable with the said testing technique or you need any help, please contact IAM team by creating a Service Now incident.

Detailed testing steps

macOS

  • Use your favorite text editor to add an entry to /etc/hosts file. The following snippet shows the entry that needs to be added. Please note that when editing the hosts file you will need to enter the administrator password for you Mac.

    (base) ap349@Amits-MacBook-Pro ~ % cat /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost ####################################################### # Added for testing Shibboleth Upgrade ####################################################### 128.36.64.54 auth.yale.edu

  • Use your favorite browser to logon to the application. In this case we will logon to Service now by navigating to https://yale.service-now.com. Please note that you will get a certificate error which is expected, hence we will ignore the error and continue to the application

After completing the test, please remember to remove the added entry from your hosts file.

Windows

  • Please refer to How to Edit Your Hosts File on Windows, Mac, or Linux (howtogeek.com) for steps for updating the hosts file and add the following entry

    # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost ####################################################### # Added for testing Shibboleth Upgrade ####################################################### 128.36.64.54 auth.yale.edu

  • Use your favorite browser to logon to the application. In this case we will logon to Service now by navigating to https://yale.service-now.com. Please note that we will get a certificate error which is expected, hence we will ignore the error and continue to the application.

After completing the test, please remember to remove the added entry from your hosts file.