...
Condition Evaluated | Reason | |
|---|---|---|
A1 | the document root element is md:EntitiesDescriptor | [SAMLMeta] sec. 2.3 |
A2 | all required namespaces are declared, that is md, mdrpi, mdui, shibmd | [eduGAIN-profile] sec. 1.3 |
A3 | md:EntitiesDescriptor contains md:Extensions element with mdrpi:PublicationInfo element in which the publisher and creationInstant attributes exist | [eduGAIN-Profile] sec. 3 |
| A4 | the creationInstant attribute uses the dateTime format required by SAMLMeta and does not point to the future | [MDRPI] sec. 2.2.1 |
A5 | validUntil attribute in EntitiesDescriptor element exists, can be converted to a time value and it does not point to the past | [SAML] lines: 348; 316 |
A6 | validUntil attribute with a value not earlier than 120 hours (5 days) and not later than 2304 hours (28 days) after the creationInstant | [eduGAIN-profile] sec. 3 |
A7 | the fetched document schema-validates against following SAML metadata schemas:
| list of schemas from Shibboleth Metadata Aggregator configuration and pyFF sources |
For each md:EntityDescriptor element the following verification is performed:
...
a federation metadata feed is unavailable (the corresponding federation feed channel is not responding)
a federation metadata feed does not validate correctly
an alert is raised and delivered to the Operational Team. An error status is set on the eduGAIN status page https://technical.edugain.org/status and the cause of the error is displayed in the details section. The remaining cache time is also displayed. The status is also available through the eduGAIN access API, as described on: https://technical.edugain.org/monitoring. If the error condition persists reminder messages are sent in the intervals of 6 hours. If the federation metadata feed can be accessed/validated again, a recovery message is delivered to the eduGAIN OT.
During every aggregation run the validUntil timer for each of the federation metadata feeds is performed.
- If the remaining validity period is below 96 and above 12 hours an alert is raised once a day at 14 hour UTC.
- If the remaining validity period is below 12 and above 6 hours an alert is raised every second hour.
- If the remaining validity period is below 6 hours an alert is raised every hour.
Detailed technical description
Metadata acquisition
Federation public keys, federation feed channel locations (metadata URL), registrationAuthority strings are stored in the eduGAIN database.
Aggregation process is performed in the following steps:
all federations with the status “in production” are selected from the eduGAIN database
for each federation its metadata URL is used to access federation metadata feed
the metadata URL is contacted by presenting If-None-Match and If-Modified-Since header values from the last successful metadata fetching process (conditional GET support)
the response 304 means that metadata was not modified - in this case the latest saved copy is used in aggregation process
the response 200 means that a new metadata feed is available
the eduGAIN validator is run against any new metadata feed
any feed error generated by the eduGAIN validator triggers the appropriate report, the offending metadata is rejected and the last successful saved copy is used instead if it is still valid
any successfully checked metadata feed is saved locally
Metadata validation
Each freshly downloaded federation metadata feed is processed in order to verify integrity and originality and the adherence to all required standards and policy conditions.
Signature verification is handled with the Shibboleth Metadata Aggregator v. 0.9.2
Schema conformance validation is handled with the Shibboleth Metadata Aggregator v. 0.9.2
Additional conditions, in particular those defined by the [eduGAIN-Profile] are handled by eduGAIN specific code in the eduGAIN validator implemented in Python with lxm and OpenSSL modules.
Metadata combination and collision handling
All valid federation metadata feeds are passed to the aggregator in a sequence ordered according to the date when federations have started to supply data to eduGAIN. During aggregation the first occurrence of a given entityID will be used in the resulting eduGAIN metadata aggregate, any of the following occurrences will be discarded.
It should be noted that this algorithm makes it possible that an entity being served by one federation will be later replaced by its version from another federation if this latter federation comes first in the processing order.
Metadata aggregation is performed with pyFF (currently 0.10.0dev)
. Detailed description of alert procedures is provided on the alerts page.
Detailed technical description
Metadata acquisition
Federation public keys, federation feed channel locations (metadata URL), registrationAuthority strings are stored in the eduGAIN database.
Aggregation process is performed in the following steps:
all federations with the status “in production” are selected from the eduGAIN database
for each federation its metadata URL is used to access federation metadata feed
the metadata URL is contacted by presenting If-None-Match and If-Modified-Since header values from the last successful metadata fetching process (conditional GET support)
the response 304 means that metadata was not modified - in this case the latest saved copy is used in aggregation process
the response 200 means that a new metadata feed is available
the eduGAIN validator is run against any new metadata feed
any feed error generated by the eduGAIN validator triggers the appropriate report, the offending metadata is rejected and the last successful saved copy is used instead if it is still valid
any successfully checked metadata feed is saved locally
Metadata validation
Each freshly downloaded federation metadata feed is processed in order to verify integrity and originality and the adherence to all required standards and policy conditions.
Signature verification is handled with the Shibboleth Metadata Aggregator v. 0.9.2
Schema conformance validation is handled with the Shibboleth Metadata Aggregator v. 0.9.2
Additional conditions, in particular those defined by the [eduGAIN-Profile] are handled by eduGAIN specific code in the eduGAIN validator implemented in Python with lxm and OpenSSL modules.
Metadata combination and collision handling
All valid federation metadata feeds are passed to the aggregator in a sequence ordered according to the date when federations have started to supply data to eduGAIN. During aggregation the first occurrence of a given entityID will be used in the resulting eduGAIN metadata aggregate, any of the following occurrences will be discarded.
It should be noted that this algorithm makes it possible that an entity being served by one federation will be later replaced by its version from another federation if this latter federation comes first in the processing order.
Metadata aggregation is performed with pyFF (https://github.com/IdentityPython/pyFF, currently v. 1.1.2.dev0 is used).
Software updates
Updates to crucial aggregator elements, in particular pyFF, may result in a changed format of resulting metadata aggregate. Any such change will be announced to the eduGAIN SG mailing list. If the OT observes that the update indeed introduces changes to metadata, a beta feed will be created and announced to the SG and a change on the production will be delayed by a two-week testing period. A reminder will be issued a week before the actual change of the production feed.
Acknowledgment
This document borrows heavily from Ian Young’s https://gist.github.com/iay/7486653
...
[SAMLMetaIoP] https://www.oasis-open.org/committees/download.php/36645/draft-sstc-metadata-iop-2.0-01.pdf
[eduGAIN-Profile] https://githubtechnical.edugain.comorg/REFEDS/SAML-Profile/blob/master/edugaindoc/eduGAIN-saml-profile.mdpdf
[eduGAIN-OPS]