During normal maintenance, the only configuration you change is to add new Relying Parties with Metadata and Attribute-Filter rules (and perhaps new Attributes). That is documented elsewhere. This page is to describe other Shibboleth configuration changes that Yale has made. Chances are you would only see these changes if you compare Yale configuration files checked into the Install Project with unmodified Shibboleth configuration files from the distribution zip, and that will only happen when you are upgrading from one release of Shibboleth to another.
The configuration rules and syntax are defined in the Shibboleth Wiki pages, so the purpose of this document is to either explain why Yale did what it did or to provide useful pointers to Yale Developers when they have to solve problems. The configuration will be described file by file.
The CAS Integration
Starting with Shibboleth 3, Yale uses the CAS-Shibboleth integration written by Unicon. This is mostly documented in the Unicon project at https://github.com/Unicon/shib-cas-authn3
This has nothing to do with the Shibboleth internal support for replacing CAS with their own implementation of the CAS protocol. It is also different from the older verison of the Unicon code for Shibboleth 2. The documentation is in a Git Hub repository where you might be tempted to download the source, but generally you do not need to recompile anything. Simply follow the links in the documentation to download the JAR files.
There are two ways you can manage the integration using Yale project management rules. You could put the jar files into the Shibboleth artifact, which would probably be the right thing to do since they are code and not configuration text files. Currently, however, we use the second option and check them into Source Control as part of the Install project even through the jar files are not "source". We may move them to the artifact later on, but for now putting all the Yale configuration dependencies in one spot seems simpler.
Any CAS integration has to provide two parameters. You need the URL of CAS itself, and you need a URL or host name for the service string you send to CAS. You might think that the code could get the second parameter from "hostname", but most of our servers have more than one host name and it is impossible for Unicon when it writes the code to guess which name is the right one to use. These two parameters are in the install-XXX.properties files (where XXX is DEV, TEST, or PROD).
# The CAS Server and the service= we pass to it. cas.server.url=https://auth-dev.yale.edu cas.target.url=https://auth-dev.yale.edu ###### TEMPORARY VALUE USED WHILE ONLY ACCESS TO DEV IS SSH TUNNNEL #cas.target.url=http://localhost
These parameters are for DEV. The DEV CAS server is "https://auth-dev.yale.edu/cas". So the cas.server.url includes this part of the URL up to but not including the /cas part. The Unicon code will add the /cas/login and /cas/validate parts as it needs them.