Background
The SAML Single SignOn protocols exchange data between the Application and Shibboleth through the Browser. We do not use the protocols where the Application talks to Shibboleth directly.
The simplest Shibboleth SSO solution is what is called "IdP Initiated" (that is, Shibboleth sends an unsolicited login SAML message to the application). The user triggers this by sending clicking on a link or pasting a URL into the Browser of the form:
...
Audience
If you are an application owner testing a new version of Shibboleth before it goes into production, or if you are testing a new application that has not yet been configured to the production Shibboleth server, then you want to look at the instructions for configuring a desktop system to use Pre-Production Shibboleth. See Testing Your Application before a Shibboleth Change.
This document provides instructions for a Shibboleth developer who needs to test a Sandbox Shibboleth running on his desktop under Tomcat, or to test new VMs in the machine room for a future release of Shibboleth that has not yet even replaced the DEV or TEST environments.
Background
Generally speaking, you can test proposed changed to Shibboleth using https://auth-dev.yale.edu/idp and https:/profile/SAML2/Unsolicited/SSO?providerId=nobody/auth-dev.yale.edu
This URL points directly to a Shibboleth instance, which could be auth, auth-test, auth-dev, or localhost:8080 in the Sandbox. The string after the providerId= parameter is the entityId string for the application. Shibboleth searches the attribute-filter.xml for attributes released to that entityId, and it searches the Metadata for a definition of that entityId. It then generates a SAML login and sends it to the configured default AssertionConsumerService URL in the Metadata. The Metadata must exist and the hostname in the AssertionConsumerService URL must exist on the network in order for Shibboleth to generate and attempt to send the SAML.
The other approach is that the user can go to an application that has been configured with a URL of Yale Shibboleth. Typically the user selects from a pulldown list or presses a button, although some applications simply redirect back to Shibboleth immediately. The application sends a SAML Request, and there are two ways that Request can be transmitted. Both involve sending data to the Browser, and then having the Browser forward that data to the configured Shibboleth URL:
- (SAML Browser POST Protocol) writes a Form to the screen containing a pre-loaded text box containing the SAML Request, then uses JavaScript to Submit the data to https://auth.yale.edu/idp/profile/SAML2/POST/SSO
- (SAML Browser Redirect Procol) redirects the Brower to "https://auth.yale.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=" followed by the character encoded SAML Request
So the three options are:
- The user click on a link sending the Browser to the Shibboleth URL
- The Application sends a Redirect to the Browser, and the Browser does a GET to the Shibboleth URL
- The Application writes a form and JavaScript Submits it to Shibboleth URL.
Shibboleth always uses the Browser POST Protocol to send the Response back to the Application (it writes a Form to the screen containing a pre-loaded text box containing the SAML Request, then uses JavaScript to Submit the data to the AssertionConsumerService URL configured for that EntityId in the Metadata).
So both Shibboleth and the Application talk only to the Browser and the Browser forwards data between them. Therefore, the network address of the Application and the Shibboleth server are always determined by the Browser and the environment of the desktop system on which the Browser is located. There are many mechanisms you can use privately on your computer (or on a VM running on your computer if you don't want to mess up your real OS):
- In 90% of the cases you can use an IdP Initiated Response, where all you need to do is to change the URL of the link (or bookmark in the Browser) to point to http://localhost:8080/idp or any other URL.
- You can temporarily change the network address of "auth.yale.edu" by putting an entry in the "hosts" table on your computer (or you could point to a dummy DNS server, but that is much harder). This captures the traffic, but it does not change the protocol or port number so generally you have to use a test Shibboleth that is running SSL on port 443.
- You can install a Browser plugin ("Redirector") that matches URL patterns and then rewrites them. It can match "https://auth.yale.edu/idp/*" (note the wildcard at the end) and replace it with "http://localhost:8080/idp/$1" (where $1 is a variable that inserts the rest of the original URL after the matched string.
- You can reroute the URL outside the Browser using a Proxy. Charles Web Debugging Proxy is easy to use and setup, while nginx is widely used and very powerful, but requires more reading because there is so much it can do.
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.
Firefox Add-Ons
SAML messages are typically BIN64 encoded and appear to be the contents of a Text Box in a form or else part of the query string. You can line up a set of tools to trace, cut, paste, decode, and format the XML, or you can install the Firefox SAML Trace add on, which does all of this work for you.
A lot of debugging can be done by using Shibboleth on your desktop (Sandbox) and setting a URL starting with http://localhost:8080/idp/..." in the Browser address bar. However, final testing may require access to the actual application using a normal login sequence. This may require the use of the PREPROD Shibboleth VM, because it has credentials (the signing key) identical to production Shibboleth and can produce a Response that the application will accept. PREPROD may have a public URL address through the F5, or it may have an internal URL that can be accessed from a desktop, or it may require that you SSH login to the host and tunnel port 8080 to your desktop. However that works, you need the Redirector Firefox plugin which watches for a particular URL pattern "https://auth.yale.edu/idp/*" and then substitutes a replacement for the original URL "http://localhost:8080/idp/$1" where $1 is replaced by the rest of the original URL (after the matched prefix).
If you click the Firefox Menu icon (three horizontal lines in the upper right corner of the toolbar) then Add-On is an option (which looks like a puzzle piece). Click it.
Go to the Add-Ons, Search for a new Add-On with the word "SAML". Install the SAML Tracer. Look for "Redirector" and install the Redirector Add On (it has a logo of a capital R ending in an arrow).
Now SAML Trace appears in the same menu, and Redirector installs an icon on the toolbar itself.
SAML Tracer requires no configuration. When you turn it on it traces Web activity in a new Window and will highlight, decode, and display the XML in a SAML Request or Response on demand. You turn it off by closing the Trace Window.
Server Access
If you run Shibboleth under Tomcat on your Sandbox 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. In 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.
Configure Redirector
Redirector requires you to create URL Remappings. What you are really doing is a Match and Replace, just like you would do in a Text editor. You can match text with either a Wildcard or Regular Expression. Wildcard is simpler and is perfectly adequate for Shibboleth testing.
The basic remapping is from "https://auth.yale.edu/idp/*" to "http://localhost:8080/idp/$1". Note that the Match string ends in the "*" wildcard character, so it matches all URLs that begin with the string. The Replace string ends in "$1" which is a variable that represents the data that matched the "*" wildcard. In English, this says, "Match all URLs that begin with https://auth.yale.edu/idp/ and replace those characters with http://localhost:8080/idp/, but leave the end of the URL alone."
You need a second remapping because of a problem with how the Unicon CAS-Shibboleth Integration works. When an application uses CAS, it creates a Service string that identifies the application to CAS and also provides a URL to which CAS returns the Service Ticket by Redirecting the Browser to the Service string.
CAS clients (including the Unicon CAS-Shib integration) are smart enough to realize that the host name of the computer on which Shibboleth is running and the port number the Tomcat service listens on may not be some internal values used only in the machine room. The Public URL for Shibboleth may be something the F5 knows, but Shibboleth cannot find this URL on its own, so you have to configure the Service URL as a property.
There is an another solution. The Browser sends an HTTP Host header containing the protocol, hostname, and port number from the point of view of the Browser before it goes through any network front end. That is exactly what we need for the Service string, although someone needs to determine the context path ("/idp") and add it on the end of the Host header information.
Unfortunately, the Unicon integration has a very strange algorithm that combines all three sources:
- It gets the protocol and hostname from a configured property. In the Yale Jenkins Install project, the property that sets this value is cas.target.url.
- It gets the port number from the HTTP Host header.
- It gets the context path from Tomcat.
Shibboleth PROD is configured with the correct official hostname:
cas.target.url=https://auth.yale.edu
If you are testing on your desktop Sandbox, nobody else cares how your private Shibboleth instance is configured, and you have to manually edit an install.properties file that overrides all other property configurations. So in this case you put in your install.properties file:
cas.target.url=http://localhost
Then if you enter "http://localhost:8080/idp" in your Browser, that also sets the Host header to "http://localhost:8080". Then the Unicon Integration takes the property value "http://localhost" appends the port number from the Host header ":8080" and the path from Tomcat "/idp" and sends the correct service=http://localhost:8080/idp to CAS.
But suppose you are going to use an SSH tunnel to a VM in the machine room. Now the cas.target.url property will be the official value for the dev/test/prod hostname through the F5. So you configure Redirector to change that URL to point to the Tunnel as described above.
The problem is that the Host HTTP header is generated by the Browser after Redirector rewrites the URL. If you convert "https://auth.yale.edu/idp/*" to "http://localhost:8080/idp/$1" then the Host header becomes "http://localhost:8080".
Now you run through the three step process that the Unicon code uses that were documented above:
- It gets the protocol and hostname from cas.target.url (and gets "https://auth.yale.edu" in PROD)
- It gets the port number from the HTTP Host header. (and gets ":8080" because that is how Redirector rewrote the URL).
- It gets the context path "/idp" from Tomcat.
So this produces service=https://auth.yale.edu:8080/idp.
Of course, the port number of 8080 is incompatible with the https protocol, but that is not really the problem. The problem is that with only one entry, Redirector is prepared to rewrite "https://auth.yale.edu/idp" but it is not prepared to rewrite "https://auth.yale.edu:8080/idp". So you need to create a second Redirector remapping entry to also map "https://auth.yale.edu:8080/idp/*" to "http://localhost:8080/idp/$1".
Now when CAS redirects the Browser back using the URL from the service= string, the Browser will also send the ticket string through the SSH port to the Shibboleth VM.
I could have just given you the two Redirector remap entries and told you to enter both of them without explaining why. Then at some point something will go wrong and you will be unable to return from CAS to Shib and there will be a strange URL in the address bar and you have no way to figure out what is wrong. This happens frequently enough that the explanation is helpful.
Also, if you try to login to another application and you cannot do it, and you end up with a "http://localhost:8080/idp" address in your Browser address bar and a "Page Not Found" error, that means that you forgot to disable the Redirector mappings in your Browser and there is no Sandbox Shibboleth and no SSH tunnel currently active.
A harder problem is when you leave the Redirector on and the tunnel active to DEV or TEST and then cannot logon to other applications like Service Now (because they do not accept DEV or TEST signatures). Best practice is to always turn Redirector off after testing/idp, then do final testing on the Pre-Production machine by changing your "hosts" file.
However, a Shibboleth developer does 90% of the testing using a Sandbox Shibboleth running on the local desktop computer.
When you are making a major Version upgrade, as we did moving from Shibboleth 2 to Shibboleth 3, then it is necessary to create an entirely new set of VMs in the machine room, with new Install jobs. A certain amount of testing has to be done with these VMs to make sure that the Installation process is working before you can even change the F5 front end to point to them in DEV or TEST. During this period, the only way to access the new VMs is to use an SSH tunnel that exposes the Tomcat running on the VM as if it were a local port on your desktop computer.
In both cases, you end up effectively going to "http://localhost:8080/idp", but even if that is the real address of Shibboleth, that doesn't mean that this is the exact URL you are always going to want to use. Sometimes you need to create an alias name for "localhost" (a.k.a. IP address 127.0.0.1). Sometimes you need to hide or translate the port number. There are several tools that can help.
Why isn't it good enough to simply get to Tomcat and the Shibboleth server application? Sometimes there is a problem created by the default HTTP Host header, the fact that the Sandbox uses http instead of https, and the default Tomcat configuration. Sometimes the problem comes from SAML.
SAML Checks
First, the usual SAML definitions of terms we have to use:
- The applications you use Shibboleth to login to (Box, Eliapps mail, IPTV) are called Service Providers (SP) and are also called Relying Parties (RP). We will use the term SP here.
- Shibboleth and each SP has a globally unique ID string called an EntityID. To make it globally unique, it is often a Web URL. The EntityID of production Shibboleth at Yale is "https://auth.yale.edu/idp/shibboleth", but the EntityID of Google Apps is just "google.com".
- Shibboleth at Yale and each SP exchange a file called Metadata. A Metadata file contains the EntityID, an encoded Certificate that can be used to validate digital signatures, and a URL. The Shibboleth "SSO" URL is where the SP redirects the Browser to login to Shibboleth, and the SP "ACS" URL is the network address to which Shibboleth tells the Browser to send the SAML "Response" message so the user can login.
- The SAML Response message from Shibboleth to the SP also contains Attributes of the user (like firstname, lastname, email address, etc.) that Shibboleth is configured to send to that particular SP.
Box and Google do not know or care that you are testing a new version of Shibboleth on your desktop. They are configured to talk to production (auth.yale.edu) and their Metadata, Certificates, login URL, and other parameters are not going to change. They will not accept a SAML Response generated by your Sandbox, so either you stop your test server from sending the Response or you accept that you will get an error message from the SP saying that the login failed to work. The trick is to configure your Browser to trace and capture the SAML Response your test Shibboleth generated, so even if the SP won't accept it, you can go back and examine the XML yourself to verify that the Subject and Attributes are correct and should be accepted eventually when you run this configuration on a real Shibboleth server.
So if a problem occurs, it is triggered by an internal Shibboleth check that occurs at the very beginning of processing before Shibboleth even fetches the attributes.
You have to provide Shibboleth with the EntityID of a Service Provider. Then
- The EntityID of the Service Provider has to be matched in one of the Metadata files configured to Shibboleth
- The Metadata file has to provide a default AssertionConsumerService (ACS) URL to which the Response can be sent.
- A lookup for the hostname in the ACS URL must return an address.
For example, suppose you supply the EntityID of "google.com". Shibboleth will search the Metadata files and finds in google-metadata.xml a line:
<EntityDescriptor entityID="google.com"Having matched the EntityID, it now looks at the ACS statement in that Metadata file:
<AssertionConsumerService index="1" isDefault="true"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.google.com/a/yale.edu/acs"/>
<AssertionConsumerService index="1" isDefault="false"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.google.com/a/gdev.yale.edu/acs"/>
<AssertionConsumerService index="1" isDefault="false"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.google.com/a/gtst.yale.edu/acs"/>
There are three ACS locations that turn out to be for the production, dev, and test instances of Eliapps. The one with isDefault="true" is production, so that will be the URL to which the login message is sent. Shibboleth will verify that there is a machine on the network with name "www.google.com".
Of course, Shibboleth has to also look up the EntityID in the attribute-filter.xml file to know what attributes to send, and it has to find the attribute definitions. Those are all steps where your configuration can make mistakes, and errors will show up when the generated SAML Response message does not contain required data or contains the wrong value.
However, if the EntityID is not found in a Metadata file, or the Metadata file does not have a single or default ACS URL, then the request is incomplete and Shibboleth will not even start to process it.
If you actually want to login to the SP, then you need to be running the request on a Shibboleth that the SP is configured to respect. That will be Production or Pre-Production Shibboleth for most SPs, although during early testing with a new SP, it may be configured to use TEST Shibboleth. Now things are a bit more complicated because there are a long list of checks the SP will make on the SAML Response that you send it:
- The EntityID of the IdP (auth-test or auth) that sent the Response has to match the EntityID configured in the SP.
- The Digital Signature or the Response has to validate using the Public Certificate that the SP has configured for the Yale Shibboleth Identity Provider.
- The SP EntityID and AssertionConsumerService URL in the Response XML have to match what the Service Provider believes to be its own EntityID and URL.
- The first time the SP provides service to Yale users it is typically ready to accept any format of identifier. Therefore, we can initially provide either a simple Netid or a "scoped" value of netid@yale.edu. Once we start sending one format of Subject or Attribute, changing from one release of Shibboleth to another should not change the format of the attribute, or the SP will think that "joe@yale.edu" is a different person than "joe", forget any history and start with a new user blank slate.
Generally speaking, this means that final testing that goes all the way to a real login can only be done with the Pre-Production Shibboleth. However, any Shibboleth including the one on your desktop can generate a SAML Response with the XML names, values, and formats of Subject and Attributes, and if you compare the test and production XML you can see if everything is right.
IdP Initiated Logon
About 95% of the applications that use Shibboleth support "IdP Initiated" logon, where the Browser starts with a URL that points to Shibboleth and Shibboleth sends a SAML Response unsolicited to the Application. The starting URL is of the form:
https://auth.yale.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=nobody.yale.edu
The last thing in the URL, the "providerid" parameter, is the EntityID of the SP. It has to match some configured EntityID in some Metadata file. Then Shibboleth logs you in, generates the SAML Response, and sends it to the configured AssertionConsumerServer (ACS) URL in the Metadata file.
You can use an IdP Initiated Login to generate a response for every SP, unless the SP Metadata demands signed requests:
<SPSSODescriptor AuthnRequestsSigned="true"For testing purposes, you can set this parameter temporarily to "false", do your testing with the IdP Initiated login URL above, but then deploy the original Metadata to production.
If you do an IdP Initiated login to an SP that doesn't allow them, it will reject the SAML Response and you won't actually login. However, the digital signature was also probably invalid (not from production) and there may be a lot of other defects, and you probably were not planning to go all the way to a successful login at this stage anyway. You can still capture and check the Response for content.
It is not possible to test SP Initiated Login in this kind of preliminary testing configuration. Use IdP Initiated login to verify that the right attributes are being generated, and hold off SP Initiated testing until you get your code to Pre-Production.
Network Routing
When you are using IdP Initiated login, the only network routing problem is to make sure that the URL you use to send a request to the Shibboleth server matches the URL configured in the Shibboleth server for the CAS Service.
The CAS configuration is the "cas.target.url" parameter. When you run Shibboleth in the desktop Sandbox, it is convenient to set this property in the install.properties file you edit in your Install Project. However, if you are building new DEV and TEST server VMs in the machine room, this parameter will have been set by the install-DEV.properties or install-TEST.properties file.
So on the server you want to test, you might have:
Sandbox - cas.target.url=http://localhost:8080
TEST - cas.target.url=https://auth-test.yale.edu
What you need to do is to figure out how to run the test from your client machine using the same URL for the IdP Initiated login that was configured as the cas.target.url. In the Sandbox, all you have to do is use "http://localhost:8080" in both cases and you are done.
If you have a TEST configured VM that you are accessing through an SSH tunnel from your machine to the VM in the machine room, you have a problem. The tunnel makes the machine look like it is "localhost:8080" but the cas.target.url claims that it is https://auth-test.yale.edu.
So this document explains several tricks you can use to fix that.
Preparation
Get Firefox. You can can certainly use other Browsers in production, but Firefox is needed to test.
Firefox Add-Ons
SAML messages are typically BIN64 encoded and appear to be the contents of a Text Box in a form or else part of the query string. You can learn to manually locate and decode these strings, but the SAML Trace addon to Firefox does all the work for you.
If you click the Firefox Menu icon (three horizontal lines in the upper right corner of the toolbar) then Add-On is an option (which looks like a puzzle piece). Click it.
Go to the Add-Ons, Search for a new Add-On with the word "SAML". Install the SAML Tracer. Look for "Redirector" and install the Redirector Add On (it has a logo of a capital R ending in an arrow).
Now SAML Trace appears in the same menu, and Redirector installs an icon on the toolbar itself.
SAML Tracer requires no configuration. When you turn it on it traces Web activity in a new Window and will highlight, decode, and display the XML in a SAML Request or Response on demand. You turn it off by closing the Trace Window.
VM Access
If you run Shibboleth under Tomcat on your Sandbox 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. 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 put in an AD Group to use this type of VPN, and you have to download the Profile files for these special VPN targets. Get help from another developer if this is not set up on your machine or for your Netid. Access to the VPN requires MultiFactor Authentication even though your desktop is on campus.
When the VPN is enabled, you may have access to http port 80 and https port 443 using the native VM hostname (vm-something-01.its.yale.internal). That may be good enough for testing.
In other cases, you may need use an SSH tunnel for ports 8080 or 8443, but it is almost impossible to test or debug anything without SSH access to VMs and log files anyway. SSH requires that Operations create 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. In 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.
Configure Redirector
Redirector runs inside your Browser. Every time the Browser is about to go to a network URL, Redirector inspects it. If the destination URL matches a pattern, Redirector replaces the string with a different string. This is essentially the same as the Find and Replace function of every Text editor. You can match text with either a Wildcard or Regular Expression. Wildcard is simpler and is perfectly adequate for Shibboleth testing.
The basic remapping is from "https://auth.yale.edu/idp/*" to "http://localhost:8080/idp/$1". Note that the Match string ends in the "*" wildcard character, so it matches all URLs that begin with the string. The Replace string ends in "$1" which is a variable that represents the data that matched the "*" wildcard. In English, this says, "Match all URLs that begin with https://auth.yale.edu/idp/ and replace those characters with http://localhost:8080/idp/, but leave the end of the URL alone."
There is a problem because Redirector replaces the hostname before the Host header is generated. Therefore, Shibboleth may have properties that tell it to generate a hostname of "https://auth.yale.edu", but it gets an HTTP header of "Host: http://localhost:8080".
Initially, this will cause trouble when the Unicon CAS-Shibboleth integration generates a Service string to send to CAS. After login, CAS redirects the Browser back to the URL in the Service string, which you will discover has been set to "service=https://auth.yale.edu:8080/idp". You can get around this in one of two ways.
If you are testing on your desktop Sandbox, nobody else cares how your private Shibboleth instance is configured, and you have to manually edit an install.properties file that overrides all other property configurations. So in this case you put in your install.properties file:
cas.target.url=http://localhost
Now the property value in the properties file and the rewritten Host header are the same, and the Service string becomes "service=http://localhost:8080/idp" and it works. However, this is generally not a viable choice for a VM in the machine room which you probably do not want to configure with a "localhost:8080" property.
So you need to create a second Redirector remapping entry to map "https://auth.yale.edu:8080/idp/*" to "http://localhost:8080/idp/$1".
This second remapping entry rewrites the URL that the Unicon integration generated and sent to CAS to the working network address of the test server you are using.
Unfortunately, this will not solve a mismatch problem between the "destination" string generated by an application when you go the the application first and it generates a Request and the URL Shibboleth generates to validate the destination. The application will generate the official production URL for production Shibboleth ("https://auth.yale.edu/idp") but unfortunately the Spring Beans configured by default in the Shibboleth /system directory generate the protocol that they use to compare against this string from the actual protocol (http or https) through which the Request arrived from the Browser. No matter how many tricks you use to rewrite or modify stuff, if the Request arrives as http over 8080, then Shibboleth will generate "http://..." and that will fail to match the "https:" in the Request XML.
So if you are doing a final end-to-end login test of one of the applications that require you to go to the application first and get a Request object, then Shibboleth has to be running under a Tomcat configured to use SSL, and the Host header generated should have no port number.
Charles Web Debugging Proxy
...