Content Comparison

...

This document is not expected to be used by ordinary users. It has a slightly higher level of technical content, but everything is explained and it requires no special background. 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.

...

1. Copy the test "hosts" file to the "etc" directory. To make sure it is working, issue the command "ping auth.yale.edu" and verify that the address being used is 128.36.64.90.
2. Launch a "Private Browser Window" so you have no existing session with CAS, Shib, or your application.
3. Login to your application using the browser. If it works, the test is successful.
4. Copy the original saved file to the "etc" directory.

If the login is not successful, then send mail with the URL you used to do the login, the netid you used, and contact information to Howard.Gilbert@yale.edu.

What happens if you do not restore the original copy of the file? It is possible to run for weeks using the Pre-Production version of Shibboleth and everything will work. Unfortunately, there are a few other applications Yale services that you can access that appear to be running on the "same server name. A few applications have obsolete references to CAS as https://auth.yale.edu" server, but only Shibboleth (that is "https:///cas/login. This isn't an actual version of CAS, but a small program that sends the user to the correct server name. These other minor functions nominally on auth.yale.edu /idp") is supported by the test machine at 128.36.64.90are not simulated by the Pre-Production Shibboleth server address. So if you leave the hosts file pointing to the test configuration, and then a few days later you use some application that was configured years ago to use a obscure alias of CAS as "https://auth.yale.edu/cas" then that CAS URL will not be found. So generally it is a good idea to run one quick test and put things back to normaladdress and happen to follow a link to one of these old URLs, then you will get a Not Found error message.

Security

The hosts file has been in every system that uses the Internet. On Windows it goes back at least as far as the mid 1990's. What we are doing here was once very common.

...

All Browsers have an Advanced section of their Options where under Network you can configure a Proxy Server. When we have the time, we will set up a Proxy Server and then you can test Shibboleth using a change to the Browser configuration instead of a change to the hosts file. Doing this is actually a bit more complicated, but because of the bad association of hosts file changes and malware, some people today may feel better about this change. We have not yet set up the proxy.

We have also set up a Windows VM in the "SpinUp" test environment that always has the modified hosts file. If for some reason you do not want to make the hosts change on your computer, you can request that your Netid be added to the users who can login to that computer, and then you can perform the test through the Remote Desktop session.

Generally speaking, it is not possible to change the hosts file on a normal (non "rooted") Android computer, so you cannot test from a phone or tablet.

Changing the hosts file is simple and easy to understand.