Content Comparison

...

The process is fairly simple, but it involves making a temporary administrative change to a laptop or desktop computer under your control. You add one line to a system file, test, and then restore the original version of the file. It doesn't matter what computer you use, so if you don't like doing this on your important machine, find something that boots up at all and run the test there.

What about TEST?

There is a TEST version of Shibboleth on the network at "https://auth-test.yale.edu/idp". If you have a TEST version of your application, you can configure it to use TEST Shibboleth and then your problem is solved. Just login through the TEST environment.

However, in 99% of real world cases most people have only the one production version of their application, and they cannot easily switch it back a forth between "auth.yale.edu" and "auth-test.yale.edu". Fortunately, you do not actually need to change the application. You just need to change one browser on one test desktop.

Names and Addresses

Applications do not talk to Shibboleth directly. They send a URL to the Shibboleth server back to the client Web Browser, and the Web Browser talks to Shibboleth. When Shibboleth sends data back to the application, it digitally signs it to prove that it is authentic and has not been modified in route.

An application may know that Yale Shibboleth is "https://auth.yale.edu/idp" and it will provide this information to the Browser. It is up to the Browser to actually find the Shibboleth server, get the response, and send the data back to the application. Normally your browser will look up the "auth.yale.edu" name in the Yale Nameservers, and they will return the official answer that that name is associated with Internet address "130.132.35.36". That address sends the Browser to our production Shibboleth VM.

However, every operating system since the beginning of the Internet has had an alternate way to resolve names locally using the "hosts" file. On Windows this is located at

c:\Windows\system32\drivers\etc\hosts

and on Mac and Unix systems it is just "/etc/hosts". Every line in a hosts file that begins with "#" is a comment and is ignored. Otherwise, a line in this file contains an IP address and one or more host names associated with this address. Because the hosts file is searched first, anything found there overrides the name lookup. So if you add one line to the file in the form

128.36.64.90  auth.yale.edu

Then whenever a program looks for the name "auth.yale.edu" it goes to address "128.36.64.90" (the address of the pre-production VM for Shibboleth) instead of "130.132.35.36".

To test your application you

1. save the old hosts file
2. make this one line change to the file
3. login to your application using the browser
4. restore the original copy of the file.

Security

A number of malware programs try to modify the hosts file. They want to trap all your Browser requests and send them to some bad server somewhere. So this file is moderately protected. In Windows, for example, you need to be an administrator to change the file and you have to give an administrative OK. Generally you cannot edit the file directly. Make a copy of it to another directory. Then create a second copy with the one line change. If you drag and drop the modified file to the original directory, you will be asked if you want to replace the old file and then be asked for administrative approval of the change. You repeat this sequence to replace the temporary modified copy with the saved original file.

What happens if you do not restore the original copy of the file? The pre-production version of Shibboleth is protected by the same security as production Shibboleth. It is just changed more easily and quickly. Unfortunately, there are a few other applications that you can access that appear to be on the "auth.yale.edu" server, but only Shibboleth (that is "https://auth.yale.edu/idp") is supported by the test machine at 128.36.64.90. So if you forget, and a few days later you accidentially try to access "https://auth.yale.edu/somethingelse" then that will fail. So generally it is a good idea to run one quick test and put things back to normal.