...
Supervision of eduGAIN joining process
The task of chairing the eduGAIN SG lies within the Operational Team. The SG chair supervises the joining process of new members, sets up consultations, handles voting, keeps the documentation of the process. As a part of the joining process federations are required to provide contact and technical information including sensitive factors such as public keys used for signature verification.joining process support has been assigned to the Operational Team, but decision making and organising the voting process currently lies within the eduGAIN SG and its chair. The OT handles all technical details of joining, like metadata validation, signing certificate handling etc. Any paperwork is handled by the eduGAIN secretariat provided by GEANT.
eduGAIN operational model and availability of services
eduGAIN core function is the metadata exchange point. Federations supply their own metadata and download aggregated metadata to supplement their own and redistribute them within their federation members. Federations are strongly discouraged from pointing any of their members directly to the eduGAIN MDS. Within this operational model even a relatively long (several hours) downtime of the MDS does not cause any disruption that could be noticed by individual identity or service providersThe operational baseline of MDS availibility is set at 99% for any given month. The unavailability details are provided at eduGAIN Services Status and system changes are listed at https://technical.edugain.org/system_updates.
While every care is taken that all eduGAIN services function reliably, the selected operational model allows that services updates and modifications can be done at a short-term notice allowing for a small risk of a downtime required to restore the system snapshot.
...
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.
If the OT decides that a notification needs to be sent to the federation, the official contact address registered be the given federation is used. If one of the following conditions is met:
- there is a immediate reject from the federation mail server,
- there is no reply within 24 hours,
- the metadata validUntil period is under 14 hours
then the OT sends additional notifications to the federation delegate and the deputy using their e-mail addresses registered by the given federation.
If it becomes likely that a given federation may not be able to react in time and that its cached metadata feed may expire, the eduGAIN OT sends a warning to the eduGAIN SG mailing listand to the contact address of the Federation that is affected. There is one exception to that rule - metadata unavailability alerts are sent to the OT only to avoid possible false positives caused by temporary network problems. The OT then makes its own decision when to contact the Federation.
It must be realised that that the case of all entities supplied by a large federation being deleted from eduGAIN has heavy consequences - other participating federations will naturally have to drop these entities. When the federation metadata feed becomes available again, other federations may be forced into running emergency regeneration of their metadata, service providers may observe limited breaks in their service. Therefore the eduGAIN OT is making all possible effort to avoid such situations. If the eduGAIN OT realises a very special situation it is allowed to temporarily stop aggregation in order to avoid the deletion of of the federation but it MUST immediately notify the eduGAIN SG that such measures have been taken.
...
- 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.
- The unavailability details are provided at eduGAIN Services Status.
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
...
- The edugain-db and mds-feed hosts are located in a secured private network and can be accessed only from a single host in the PSNC network.
- The access to this single host is only available over SSH and only from a limited list of IP addresses.
- The federation signing keys can only be stored in the edugain-db with a process that needs to be run directly on the db host. This requires that the OT copy the key to the database host and run the process manually. The key is added to the database only when the decision to actually admint the federation metadata to eduGAIN has been taken. This is an additional security procedure guarding against a mistake in assigning the level of participation for a federation.
- The eduGAIN signing key is stored on the mds-feed host, where the whole process of aggregation and signing is run hourly. This host cannot be reached from the external network. The resulting signed aggregate is then moved to the distribution host as described in the Metadata aggregation related procedures section.
References
[eduGAIN-CONST]
[eduGAIN-BCP]
[eduGAIN-meta]