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 setup.
SAML Messages
The most important part of any Shibboleth generates a SAML message (called login to an application occurs as it generates a "SAML Response" ) that it sends to eachr of our Service Providers (such as box, google, service-now, archer, and so on). There is a tiny amount of important content in the Response buried in XML message and sends it to the Service Provider. The message contains a large amount of meaningless XML junk. If the Service Provider accepts the message, then the user logs on to that serviceXML boiler plate and a very small amount of important content.
In order for Shibboleth to generate and for the Service Provider to accept the SAML Response to work, it has to pass a long list of checks:
- The EntityID (an arbitrary but unique identifying string) of the Service Provider has to be matched in one of the Metadata files .configure to Shibboleth
- The Metadata file has to provide the correct an AssertionConsumerService (ACS) URL to which Shibboleth sends the SAML Response message. This is called the AssertionConsumerService or ACS URLResponse can be sent.
- The Digital Signature generated by Shibboleth has to be validated by the Public Key or Certificate configured for Yale in the Service Provider application and the EntityID name that Shibboleth uses to identify itself also has to match. In practice, this means that a Service Provider configure with PROD Shib has to get a message from a server configured with the private key credentials and EntityID of PROD Shib, while a SP that expects a message from TEST needs a message signed with the TEST key and sent with the TEST EntityID.
- The message will contain the EntityID and ACS URL of the Service Provider. SAML messages have an implied "eyes only" rule, so these two strings have to exactly match the EntityID and ACS URL that the Service Provider expects. Since these two values came from a Metadata file the SP sent us, this check is usually never a problem.
- The message does not contain any information about the network address or server name of the Shibboleth server. So it is not important that Shibboleth run on any particular machine.
- The SAML Response must contain any attributes that the Service Provider has told us are required. Generally speaking, across any change to Shibboleth the value of each attribute should not change. If the user changes their name or email address, then Shibboleth will start sending the new attributes, but the attributes should not change if Shibboleth switches to a new database or we put in a new version of Shibboleth.
- Each SAML message contains a Subject. In most cases the Subject is ignored, but there are a few special cases that also turn out to be really important cases (Google for EliApps, Service-Now) where the Subject is the only field and it is special and must have the same value each time.
...