...
Metadata files can define a single partner entity, or a list of entities. The list of Metadata sources is configured in the relying-party.xml (Shib 2) or metadata-providers.xml (Shib 3) primary configuration file, and every time that file changes Shibboleth reads in a new copy of all its Metadata sources. Otherwise, individual sources of Metadata can be configured to be periodically checked for an update and new Metadata is read in to replace the old source when the file timestamp changes.
...
- Static - Most Yale Metadata files are stored in disk files that are only changed by a full Jenkins configuration install. They are not individually checked for timestamp changes. Instead, when Jenkins Install updates the relying-partly.xml files and changes its timestamp, the new copy of that file is read into memory (even if it didn't really change content) and then all the Metadata files it defines are also refreshed in memory. All these Metadata files refresh together.
- Remote - This option is only used for InCommon. Every 8 hours Shibboleth checks a configured URL to see if the Metadata for InCommon has changed. If so, it downloads a new copy of this information from the remote Web Server, stores a local copy of this file on disk where it can be used as a backup if a network connection to InCommon is not available the next time Shibboleth starts up, and then replaces the in-memory old copy of the InCommon Metadata information.
- Dynamic - Prior to 3/15/2015 Yale did not have any individual Metadata files that could be updated by themselves. In the new configuration, there are three types of individually replaceable Metadata.. Because Shibboleth examines Metadata sources in the order in which they are configured, and it stops when it finds Metadata for the entity for which it is searching, these dynamic Metadata files are distinguished by their position in the search order.
...
- Specific Metadata file sources are configured to be checked periodically for changes and to reload. There is an initially empty metadata file at the start of the search order, one at the end, and two files for frequently changed metadata have been configured to check every minute for changes. However, we can add the parameter to poll and refresh data to any other Metadata file.
Because the search for Metadata stops at the first file (provider) that contains a matching EntityID, there is a strategy for using dynamic metadata files reflected in the runtype parameter on the Jenkins job.
The "emergency-override" dynamic file comes first in the search. Metadata placed in this file can file with an EntityID that matches an existing Metadata entry in a later file will logically replace the previous version of production Metadata for any partner. After each new Shibboleth Release, this file is empty. Metadata is can be placed in it when we have an incident because an existing partner metadata has failed (typically because it has expired or the Certificate and key used by the partner has changed unexpectedly). This provides a safer form of "emergency" fix because only the one Metadata element is logically replaced instead of the entire Shibboleth configuration.
The "additions" dynamic file comes last in the search, so it cannot be used to change any existing Metadata for any entity. It . Every existing Metadata file will have already been searched, and all existing EntityID values will have matched, so you do not get to this file unless you have a new EntityID that doesn't match any existing on (including all the InCommon entities). This file can only define new Meatadata for new entities. This becomes a relatively safe Standard Change because anything put into this file cannot adversely affect existing configured services. A new partner may need more than just Metadata. They may need attributes released to them. Fortunately, Shibboleth allows the function of the attribute-filter.xml file to be broken up into multiple files. Existing partners are configured in attribute-filter, and an empty file named "additional-attribute-filter.xml" is deployed with every Shibboleth Release. Therefore, if a new partner has to be defined to production and cannot wait for the every-other-Thursday Release cycle, the Metadata for that partner can be placed in the metadata/additions.xml file and the attributes to be released can be put in the additional-attribute-filter.xml file. A Jenkins install of runtype=additions replaces both of these originally empty files with the data for the newly defined partner while guaranteeing by their search order that they cannot interfere with existing services. When the next regularly scheduled Shibboleth Release is ready, the changes move from the additions files to the normal Shibboleth configuration and the additions files are empty again.
...
In vanilla Shibboleth, the only errors that are caught during Attribute evaluation are query errors. Any other error (during JavaScript evaluation, or because of Shibboleth bugs) is fatal and prevents the user from logging on to any partner. Yale has added code to wrap other evaluations with a try-catch that discards attributes in error but preserves all the other attributes. Because attribute errors tend to occur only in new attributes not widely in use or old abandoned attributes no longer in use, this makes Shibboleth more robust against real world errors without impacting security. We will try to interest the Shibboleth maintainers in making this fix standard.
The same value One column/property returned by a query may be used to generate with many different Attributes with various friendlyName and name values. There are either no real standards, or too many real standards (which is pretty much the same thing). The first name AttributeDefinition statements, each with a different id name and each with a different Encoder configuration. This generates different SAML statements in which the same value is given different names to different partners who expect those names. Some partners like the old LDAP names that are actually a string of numbers. Some like newer Oasis standard names that look like a URL. Some partners simply make up a name and expect us to provide it. The value of firstname in the database column could be used to generate attributes for SAML that labels it as "FirstName", "firstName", "first_name", "givenName", "Given Name", and slightly more sophisticated partners will ask for one of three globally unique technical identifiers ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "http://schemas.xmlsoap.org/claims/FirstName", and "urn:oid:2.5.4.42"). In part this is caused by the convention addition to different technical standards, there is also confusion because in the Far East for the first name to be the family name, while in the West that is the last namefamily name comes first and the individual name comes last.
It is also possible to define several Attributes with the same SAML Encoder name string, but with different values. For example, the simple attribute with name "mail" (the preferred E-Mail address) can be an alias or a direct mailbox address (that is, it can be howard.gilbert@yale.edu or howard.gilbert.eliapps@bulldogs.yale.edu). Which mail address to send depends on whether you are logging into Box or Coursera. So alternative Attributes with name "mail" are defined and given values, and then one of them can be released to each partner using the attribute-filter filecan refer to the Yale primary Email alias or it can refer to the native mailbox name of the primary account, and I suppose for some partners in some cases it might refer to a non-Yale preferred mailbox. Each AttributeDefinition will have a unique id string, and you should be careful not to release to any party two attributes with the same SAML name but different values because that will just confuse them.
Attribute-Filter
The attribute-filter.xml file has a long list of rules listing the Attributes (defined in the previous section) that are released to each partner. For example
...