...
During testing you may do everything on your desktop, or you may bypass the F5 and go directly to the VM over the SSH tunnel. Either way you have to be aware of the hostname configured as a property to the Shibboleth to which you are talking, and you have to consider what Host header the Browser is going to generate and whether it will be modified before it gets to Shibboleth. Otherwise,
Typically if you get halfway through to the right Shibboleth test and suddenly the Browser gets redirected to an unexpected network address that is not your Shibboleth test machine.
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 server in the first place, then all the Redirects will go back to the right machine. A configuration/test problem typically shows up if you try to change ports or protocol (http or https). So if the original URL was "https://auth.yale.edu/idp" and you try to test against "http://localhost:8080/idp" then problems with configuration or Host header mapping will show up when your Browser generates an error page and the address bar shows "https://auth.yale.edu:8080/idp/*" to or "http://localhost:8080: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 "".
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". 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 "
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/$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:
...
" 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
...
So this produces service=https/*" to "http://auth.yale.edulocalhost:8080/idp/$1".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
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: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") 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
...