Page History

...

...

As a principle requirements for federation feeds must be based on either general standards to which eduGAIN SAML profile adheres or on the eduGAIN SAML profile. In the case of standards, the experience shows that certain violations are only discovered when reported by participating federations - not all such violations are reported by standard schema validation tools, ot rt in fact not all are just schema errors. Whenever a new problem is reported, the OT makes an assessement assessment whether it inf in fact violates a required standard and if so then:

• the OT implements a new validator rule initially as a warning;
• The the OT informs the SG about adding a nev new validation rule together with an assessement assessment of which federations may be affected by it and suggests a grace period, after which the new rule will start generating an aggregation error;
• the SG members will be given the opportunity to request a longer time-frame, and eduGAIN Support will work with any participants that are currently breaching this requirement to fix the issues before the grace period ends.

...

Arising problems which cause actual interoperability issues need to be handles immediatelyhandled immediately, as described in the matadata aggregation related procedures section below.

...

Additions to metadata best current practices need to be decided by the eduGAIN SG. Each such good practice needs to practice  needs to be implemented as an eduGAIN validator warning by the eduGAIN OT. Each good practice rule needs to be implemented in added to [eduGAIN-BCP].

Metadata aggregation related procedures

...

• Half past every hour metadata acquisition is started on mds-feed and is pefromed in the following steps:

  • mds-feed downloads federation metadata feeds using conditional GET.

  • if the conditional GET resulted in a download of a new metadata file, such file is passed through the local validator instance, if validation succeeds the downloaded file is used as an input for aggregator, if it fails, the previous correct feed copy us is used instead

  • the newest available validated copy of the federation metadata feed is kept for future use

  • the validated metadata files are passed to a pyFF flow, see also [eduGAIn-meta] Metadata combination and collision handling

  • pyFF aggregates and then signs the resulting feed; currently the signing is done with key files stored at the mds-feed host

  • the resulting file is analysed, broken split into entities and used to update the edugain-db

  • the final output is uploaded with sftp to the technical host using a dedicated user account on the the technical host

• At 45 minutes past every hour the new copy of eduGAIN metadata aggregate is copied to the final destination directory and when the copy is completed the mv action is performed in order to substitute the production file in an atomic mode

• Finally the new eduGAIN metadata aggregate file is copied to the history repository and compressed

• At midnight (CET) hourly copies of metadata are deleted from the repository, leaving only a single daily file. These daily files can then be used as a source of various data analysis.

...

• All virtual machines running eduGAIN services are regularly updated.
• Before an update is planned, the local personel at PSNC are notified in the case of an update failure and immediate restore. An update forward notice is sent to the eduGAIN SG.
• In the case of large configuration changes, like moving services to new hosts, applying large infrastructure changes etc., a notice at least 7 days in advance is sent to the eduGAIN SG.
• All changes are documented in the log available for inspection at: https://technical.edugain.org/system_updates.

Backups

• system backups are performed daily as a part of the standard PSNC backup routine
• virtual machine snapshots are performed prior to system updates
• four times a year a full virtual machine dump is performed

...

• general and contact information about participating and candidate federations,
• operational information about participating and candidate federations like metadata URLs, signing keys, registrationAuthority values,
• operational information about the metadata aggregation process including details about metadata acquiring from participating federations, results of metadata validation, cache timers for individual participant federations,
• operational information about entities published through eduGAIN derived from the metadata,
• statistics derived from metadata aggregation, like numbers of entities published by individual federations and much more,
• information collected from supporting monitoring services like ECCS, CoCo.

The database is placed on a host separated from the external network, accessible only trough a limited numbers of secure hosts. Database access is realised via dedicated user accounts with access right crafted to minimize the possibility of unauthorized changes.

...

eduGAIN Metadata Distribution Service (MDS) is the central component of the eduGAIN service as a whole. For the  detailed description and procedures used in the eduGAIN metadata aggregate distributed by MDS see [eduGAIN-meta] and thethe Aggregation, signing and publishing subsection within this document. The eduGAIN metadata aggregate is produced on a separate, secured host (mds-feed). Metadata signing is also peformed on mfs-feed currently with a key file located on the host istself.

In order to minimise risks of exposing a high permissions account on the mds host the resulting aggreagate file is transferred from mds-feed to the mds host using a dedicated low premissions permissions account. The aggregate is then moved to the final place on the mds host in a process innitiated initiated within the mds host.

Organisation and management of services

...