...
FirstName: John
LastName: Doe
Email: John.Doe@yale.edu
eduPersonPrincipalName: jd345@yale.edu
Different partners can as ask for the same attribute with different names. So "John" can be a FirstName, First_Name, givenName, and so on. So you have to generate both the right name and the right value for each item.
When a new Service Provider appears, it is convenient to initially ask them to configure the EntityID and Public Key Certificate of TEST ourTEST Shibboleth. Then we can verify the attribute list, attribute names, and values and verify a login to the application. When it is all working, then we promote the changes to Production Shibboleth and ask the Service Provider to change EntityID and Certificate configuration to point to PROD.
Unfortunately, Service Providers typically have no way to go back to using TEST. In fact, our InCommon Federation has no concept of DEV or TEST Identity Providers, so the only thing they can use is our PROD Shibboleth.
Fortunately, in most cases they require a SAML Response that includes the prod EntityID and a digital signature created by the PROD private key, but they do not know and therefore cannot depend on the network address of the Shibboleth server that generated this message. This creates the need for what we call the PREPROD Shibboleth instance.
PREPROD is a separate Shibboleth server on a different VM with a different network address. Since it is not technically "In Production" we can change it any time we want to. However, it is configured with the same EntityID as real PROD, and it has a /apps/shibboleth-idp/credentials directory with the Production Shibboleth private key for signing SAML messages. So a message generated by PREPROD will be accepted by all our partner Service Providers as having come from real PROD, and they will log someone on given that message. After a few days, we lose our contacts with the person at Yale coordinating the installation and the contact at the Service Provider who is making any changes.
Very few Service Providers bother to have a permanent configuration for our TEST Shibboleth. InCommon doesn't even have a concept of configuring TEST Identity Providers to anyone. So if after a few years we need to upgrade Shibboleth and test the new release, we have to do it with all of our Service Providers configured to use only auth.yale.edu and the production Shibboleth credentials. This explains the need for a PREPROD Shibboleth.
PREPROD is a Shibboleth IdP server on a VM that has the same /credentials subdirectory (and therefore the same private key) as PROD Shibboleth. If it generates a SAML Response, all of our Service Providers will accept it as genuine. It uses the production databases. It has been installed passing a property with the production EntityID. The only difference is that it is not actually at the IP address that the DNS server reports to be "auth.yale.edu" and if a message goes through the F5 to get to it, then it will use a separate (but hopefully equivalent) configuration so it is handled the same as production.
If we can arrange that on one computer in one Browser, all traffic addressed to production Shibboleth goes instead to PREPROD, and all messages back from PREPROD are sent on to the Service Provider, then we can verify that the new code running on PREPROD works before the same code is installed on PROD.
PREPROD is necessary for final testing where it is not good enough to simply "eyeball" the SAML XML, but you really need to go all the way to login to the Service Provider and verify that you get the right account contents. This isn't necessary for ordinary day to day testing of the configuration of Service Providers, but it is necessary if someone makes a change to Shibboleth itself or do a database like IDR that provides a lot of Shibboleth data.
...