...
<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"/>
...
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
...
Some Service Providers present a login page for users. The user has to press a big button to "Login with a Netid" or "Login from Yale", or maybe they have to select "Yale University" from a long pulldown list of schools. Then the SP sends the Browser to "https://auth.yale.edu/idp/...".
This is only important if you are really going to login to the application for final testing. Before that, use the IdP Initiated format to generate a SAML Response and manually check its content to verify that Shibboleth seems to be generating the right Subject and Attributes. So you only use SP Initiated Login for final testing after that preliminary test has completed.
You will, of course, need a list of the login pages for the applications you want to test. Go to "yale.service-now.com", "yale.box.com", "mail.bulldogs.yale.edu", or the "www.yale.edu/iptv" to get started.
There are two ways an application can send its Request to Shibboleth:
- (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 Protocol) redirects the Browser to "https://auth.yale.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=" followed by the character encoded SAML Request
So, the first thing that happens in a SP Initiated login is your Browser generates a POST or GET operation to "https://auth.yale.edu/idp..." and unless you trap this URL and send it to a different location then this operation will go to the Production Shibboleth server.
If you do trap the request and send it to a test Shibboleth server, then you have a second set of problems. Shibboleth implements a set of SAML standard checks to make sure that messages have been delivered to the right server. So generally the test Shibboleth has to actually believe that it is running on a machine named "auth.yale.edu" and that it is running https on the default port.
Network Routing
In all cases, communication to Shibboleth goes through your Browser.
- The user clicks on a link sending the Browser to the Shibboleth IdP Initiated 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 on the Browser submits the form to Shibboleth URL.
So, if you are testing "https://auth.yale.edu" then the only thing you need to do is to convince Firefox running on your computer that "auth.yale.edu" is some specific network location. It can be 127.0.0.1 ("localhost") or 130.132.35.35. The question, then, is how to get your Firefox to translate that name to an IP address of your choosing.
- The trivial solution is that in the IdP Initiated login you type the IP address or real hostname of the test Shibboleth server in the URL because you control it.
- Another simple solution is to change your /etc/hosts or \windows\system32\drivers\etc\hosts file to map "auth.yale.edu" to some IP address you choose. Just remember to change it back when you are done testing.
- 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.
Adding an entry in the hosts table is simple, but all it changes is the IP address.
Redirector can be configured to change both the host name and the protocol (replacing "https" with "http") and the port number. This adds a lot of flexibility to the testing, but the URL you generate gets sent on to Shibboleth and that can cause trouble later on where Shibboleth is trying to compare its own network URL with the URL in the Request the application sent, and because Redirect changed one but not the other they do not match. That will be discussed next.
The Proxy is the most complicated configuration, but Proxies exist everywhere and so Shibboleth and Tomcat expect them to be there and have configuration parameters to take care of the problem. In production at Yale there is always the F5 proxy between the Browse and production Shibboleth, so you can certainly get away with adding a proxy between your Browser and a test Shibboleth.
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)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.
...