Page History

...

Document structure

• OT tasks

• • Management of core eduGAIN services
  • Supervision of eduGAIN joining process
  • Management or supervision of supplementary eduGAIN services
• eduGAIN services
  
  • Core services
  • Suplementarny services

• OT procedures

  • members registering or modification of supplied information

  • introduction of new eduGAIN metadata requirements

  • introduction of new good practices for metadata

  • handling of aggregation alerts

  • system updates

  • software development, testing and production implementation

  • backup

  • monitoring

  • aggregation and signing details

  Service Order

• Problem resolution

• Configuration change

• System update

• Backup

• Disaster recovery

...

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

System maintenance

System updates

• 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

Metadata aggregation procedures

The technical details of the aggregation process are described in  [eduGAIN-meta]. Here we only present the operational implementation of this process.

The aggregation, signing and publishing of the eduGAIN metadata aggregate is done on the hourly basis

All information about the system status, federation metadata channel information, federation public keys etc. is kept in the eduGAIN database and taken from there as required within the aggregation process.

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 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  [eduGAIn-meta] Metadata combination and collision handling

• pyFF aggregates and then sign the resulting feed

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

• the final output is sent with sftp to the technical host,

Handling of aggregation alerts

As described in [eduGAIN-meta], under certain conditions aggregation alerts are raised. The current practice is that these alerts are sent as e-mails to the eduGAIN OT. Since alerts are relatively rare and federation metadata feeds can be cached for at least 4 days, the eduGAIN OT makes its own decision on how to react to a particular alert. Usually before sending a notification to a federation, the OT waits until the next aggregation run to make sure that the situation has not been rectified by the federation.

...

System maintenance

Operating system and general software components

All eduGAIN core service hosts are 

...

Security considerations

The security of the eduGAIN SAML services is essentially the security of the eduGAIN aggregate. This in turn depends on:

...