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. Therefore, a test environment can be built completely on the desktop computer of the tester. Data can be traced as it passes through the Browser, and traffic can be trapped on the desktop and redirected to the test Shibboleth serverShibboleth is an Identity Provider that uses the SAML standard to logon to applications. SAML is an unimaginably complicated standard, but when Shibboleth is used in production then all the details are handled for you. In testing, however, the Shibboleth you are using will not be deployed identically to production Shibboleth. You can still get 99% of your testing done even when Shibboleth is running in a "Sandbox" on your desktop. However, now you need to know a bit more about SAML so you know how to configure the test and what things will and won't work.
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.
In testing, the SP's don't change. They are still out there on the network with the same Metadata, EntityID, and "ACS" URL. Typically they are configured to redirect the Browser to production Shibboleth, and they will always only accept a message sent by the real production Shibboleth.
So unless you are testing using the Pre-Production Shibboleth instance, you are not actually going to login to any SP. You cannot generate a digitally signed SAML Response that any SP will regard as valid, because you don't have the secret key that only Production and Pre-Production Shibboleth share. That is usually not a problem if you get used to trapping and then reading the SAML Response. You can manually validate that the Subject field is correct and that all the Attributes are correct. There still will be a final test to actually login all the way, but if you have checked all the pieces first, that test will usually be pro forma.
However, you will not get as far as generating a SAML Response if you cannot route the request to your test Shibboleth instance, or if you have configured things so that one of the components immediately regards the request as a mistake and generates an error message. Just giving a recipe for a test configuration is not enough, because when any single instruction gets missed or is misunderstood, a specific error message is generated and you need an understanding of the process to track the message back to the cause.
So part of Client setup is to understand all the sanity checks that Shibboleth and the SPs will make, why each configuration value is needed to get past the checks, and what happens when the value is entered incorrectly.
In order for Shibboleth to generate the send a SAML Response to an SP, the following things have to be properly configured on the Shibboleth server end:
- The EntityID of the Service Provider has to be matched in one of the Metadata files configure to Shibboleth
- The Metadata file has to provide an AssertionConsumerService (ACS) URL to which the Response can be sent.
...