Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The four options have been listed in increasing order of complexity, but they do not include the minute by minute difficulty during testing of turning the test environment on and off. Because changing the hosts table is usually inconvenient and provides limited function, we typically do not use that approach but include it here for completeness.

Generally you use the simplest option that can handle your test case, which means that most of the time you click on a link to a IdP Initiated operation, and you only use the other options when you have to go to the application first and get a real Request.

Preparation

Get Firefox. You can can certainly use other Browsers in production, but Firefox is needed to test.

...

If you run Shibboleth under Tomcat on your Sandbox desktop, then it is http://localhost:8080/idp. No setup is required.

This is also the URL if you create an SSH tunnel from local port 8080 to vm-shibxxx-01.its.yale.internal port 8080, but to use it you need to use VPN and SSH.

The PREPROD VM is in a machine room behind a firewall that does allow direct access from desktop computers. In normal production, only HTTP traffic gets to VMs through the F5. If the F5 has a mapping to the PREPROD VM, then you can configure Redirector to just use that public URL and you are done. However, in the new DevOps world the common practice is to put new code on new VMs that may not yet have been configured to the F5. In this case, you need to access the machine room indirectly through a VPN.

First, you need to use the standard Cisco AnyConnect client to establish a VPN session, but instead of going to the public "access.yale.edu" target that normal Yale people use from off campus, you need to use one of the special VPN targets reserved for ITS staff on campus to access a part of the network from which they can connect to VMs in the machine room. Someone will tell you the VPN target name, explain how to download the AnyConnect profile for that VPN, and put you in the AD group that has access to that VPN target nameSandbox desktop, then it is http://localhost:8080/idp. No setup is required.

If you run Shibboleth on the DEV/TEST/PREPROD VMs in the machine room and they have a public URL through the F5, then you can use that URL. If they are new VMs not defined to the F5, then the firewall will not allow access from your desktop directly to the VM. You must do an SSH login and defined a "tunnel" that forwards traffic to a localhost port to a port in the VM. You can forward http and 8080 to port 8080 on the VM, or you can forward https and port 443 to 443 on the VM.

First, you need to use the standard Cisco AnyConnect client to establish a VPN session to an area of the network from which SSH traffic is permitted to the VMs. You need to be granted permission to use this type of VPN, you have to download the Profile files for these special VPN targets, and you have to MFA authenticate when setting up the VPN.

After you have made the VPN connection, the next step is to use your preferred SSH Client to login to the VM. Operations must have created a login for your Netid on the VM and installed your SSH public key. In addition to the terminal session on the VM, the SSH client can be configured to "tunnel" one or more port number from your desktop computer to the VM. Since Shibboleth runs on Tomcat and the default Tomcat port number is 8080, you configure the VM, the SSH client can be configured to tunnel 8080 on your "tunnel" one or more port number from your desktop computer to 8080 on the VM. Now when you browse to "http://localhost:8080" the SSH Client forwards the traffic through the SSH session (and through the VPN) to Tomcat running on the VM in the machine roomIn the general case, tunnel ports 8080, 8443, and 443 to the same port numbers on the VM.

Only one program can use port 8080 on your computer at a time. When you test Shibboleth on your local Sandbox, it also uses 8080. Using the same local port number for both the Sandbox and the SSH tunnel will generate an error message if you accidentally run both at the same time. SSH will generate error messages that it cannot create the tunnel if you have forgotten to shut down the Sandbox Tomcat, and Tomcat will generate error messages that it cannot bind to the port if you forget forget to shut down SSH before starting the Sandbox. This is a feature, because you really don't want to spend hours trying to figure out what is wrong only to discover that you are debugging the wrong Shibboleth server.

...