Generally the Developer has little control over the setup of the Server and Network. Operations configures all of the network devices, the operating system, and even the Tomcat server. However, configuration problems can cause test failures, and the only way to fix these issues is to get the configuration fixed. Generally you only have to review this material when there is a major change to the network or server setupIn production, the network setup is controlled by Operations. In testing, the developer can run Shibboleth on a desktop Sandbox, or can "redirect" URLs from one host to another, or can use SSH tunnels to connect to VMs in the machine room. It is fairly easy to route a request to a selected Shibboleth server, but it can be fairly difficult to actually get it working. Shibboleth doesn't simply passively accept requests. Certain things get checked for correctness. Shibboleth can reject requests because of the way they arrived over the network, the contents of the Hosts HTTP header, and the use of https to transport the request.
Developers do not configure the F5 front end, and they generally just accept the VM that Operations gives them. So these topics are not necessarily part of a developer's technical training. This document explains a few of the complex options for transporting HTTP requests and the peculiar nature of SAML validation that can be affected by the network configuration. It enumerates the problems you may run into if you try to use a configuration other than the ones documented in the other Testing documents on this site.
IdP Initiated Login
An "IdP Initiated" test occurs when you click a URL that points to our Shibboleth server and provides the EntityID of one of our Service Provider partners:
...