Content Comparison

...

Of course, the SP will probably discard the Response because it will generally not be digitally signed correctly, and the EntityID that issued it may be unrecognized by the SP, but that is for later testing.However, there is one network configuration problem you do need to solve.

The Unicon CAS Integration

Unicon provides a Shibboleth integration provides a parameter used to define Login ("Authn") module that uses CAS. To configure this integration, the properties file must supply the protocol and hostname to use in the Service string sent to CAS, which is also the URL to which CAS redirects back its response. This string need only be meaningful to the Client Browser and does not have to have any actual meaning to CAS itself. So a Service value of "http://localhost:8080" is perfectly acceptable.The network problem is that the Unicon CAS Shibboleth integration determines the port number from the actual request, but it gets the host name from a configured property in the Yale Install Project CAS. CAS will Redirect the Browser back to this URL after it issues the Service Ticket. Unicon has a specific property name, but Yale used a different name long before we switched to using the Unicon code. We keep the old Yale property name and use it to set the new Unicon property.

So in the Install Project, you must set a property named "cas.target.url" .If you are using your desktop Sandbox and run Shibboleth in a local Tomcat, then when you Install on your desktop provide an install.properties file that definesto be the protocol and hostname of the Shibboleth server from the point of view of the Browser. When you are testing a Sandbox running on your desktop, then it makes perfect sense to set the property in install.properties and make the value to "localhost", or more specifically:

cas.target.url=http://localhost

Then if your IdP Initiated login also uses "http://localhost:8080/idp/..." then the two agree and you have no problem.

However, if you are SSH tunneled to a VM in the machine room, you need to do some research about what value of cas.target.url was supplied when that Shibboleth instance was Installed. Even if it appears to your Browser to be at localhost:8080, if that VM was installed with cas.target.url set to However, this is probably not a good value to use when Shibboleth is installed in DEV or TEST. In these cases the property is set in install-DEV or install-TEST and it will reference the "auth-dev.yale.edu" and "auth-test.yale.edu" machines. This means, then when it redirects to CAS it will set the Service string to "auth-testhowever, that if you install Shibboleth into DEV or TEST normally with these parameters, then you are not going to be able to use these VMs through an SSH tunnel (where they appear to be localhost:8080) unless you use some mechanism (Redirectory, Charles Proxy, hosts table) to rename the "https://auth-dev.yale.edu/" and CAS will try to send the service ticket back to that server. Even if they are the same machine, CAS will not recognize that the browser that is connected through the SSH tunnel is the same Browser that just sent it a Service Ticket through the public network path. You will get a message from Spring Webflow that the conversation id was not recognized.So the general rule is that the cas.target.url and the IdP initiated "Unsolicited" URL host names and protocols have to matchin the CAS Redirect to actually go to the SSH Tunnel.

You know you have this problem when Shibboleth sends you to CAS, you login, and then get a

HTTP Status 500 - Error processing ShibCas authentication request

error with a root cause of:

ExternalAuthenticationException: No conversation state found in session for key (e1s1)

What has happened is that Shibboleth received your original request from what it regards as one browser session, and it sent that Browser to CAS, but now it is getting back a response from CAS that appears to be coming in from a different Browser (although it is really the same Browser connecting to Shibboleth through a different network path using a different host name).

This error can also occur when two Shibboleth VMs exist behind a load balancing front end, but the front end has not been configured to route subsequent requests for the same session (based on the "JSESSIONID" parameter) to the same VM. Then one VM sends the Browser to CAS, but the response gets routed to the other VM.

SP Initiated

At one point I thought that it would be possible to run an SP Initiated test case to a Sandbox Shibboleth running on the local desktop or through an SSH tunnel to a VM in the machine room.

...