...
Under the term services listed are utilities as perceived by external users. The internal organisation of services, flow of information and dependencies are not relevant in this view, but are described in sections further down.
Core Services
| Name | Access location | Description | Managed by |
|---|---|---|---|
| MDS | https://mds.edugain.org | 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]. The eduGAIN metadata aggregate is produced on a separate, secured host (mds-feed) and it is copied to the distribution hosts and served form there by the http server. The file is updated hourly. | OT |
| The technical site | https://technical.edugain.org | The technical site is directed primarily at the federation level thechnical personel. It provides information about eduGAIN members, details about their participation. The technical site is also the distribution point of documentation and the home for several core and supplementary services. | OT |
| Validator | https://validator.edugain.org | The eduGAIN validator is a service designed for validating metadata adherence to standards and eduGAIN requirements. The software has been created primarily as a component for the eduGAIN metadata aggregation and the details of validation rules are given im [eduGAIN-meta]. The same software enriched by a GUI is used as a tool for manual validation of metadata and serves as a support tool for federation operators. | OT |
| eduGAIN status information | https://technical.edugain.org/status | This status page provides a view of the eduGAIN database in the part relevant to membership information and the current status of metadata aggregation. The page also displays short summary information about numbers of entities in eduGAIN. The interface provides links to scans of the eduGAIN declaration documents signed by federations, direct links to metadata validation, links to contacts, metadata sources etc. | OT |
| Entities database GUI | http://technical.edugain.org/enties | This service is an interface to the part of the eduGAIN database which stores information about entities themselves. The interface has many filtering mechanisms and also allows for CSV download for further processing in a spreadsheet. | OT |
| eduGAIN database API | https://technical.edugain.org/api | The API provides access to most of information stored in the database. In particular, the API may be used by the federations to monitor the eduGAIN aggregation process. Other uses are statistics of various sorts or even download of membership maps. | OT |
Supplementary services
| Name | Access location | Description | Managed by |
|---|---|---|---|
| ECCS | https://technical.edugain.org/eccs/ | eduGAIN Connectivity Check Service is a monitoring service for IdPs listed in eduGAIN, testing if they are actually ready for eduGAIN, i.e. if they consume eduGAIN metadata | OT |
| isFederated Check | https://technical.edugain.org/isFederatedCheck/ | This tool searches all known academic identity federations for matching organisations and then displays the results. | OT |
| CoCo monitor | http://monitor.edugain.org/coco/ | Monitoring service testing for REFEDS Code of Conduct compliance | SRCE |
| Technical testing platform | http://technical-test.edugain.org | This host serves as a playground for software development done by the operational team. All extensions are applied, tested and presented at this platform and then transferred to production using the git mechanism | OT |
| WIKI | The WIKI is maintained as a part of the GEANT WIKI space. The content is provided by many members of the community. WIKI serves as technical documentation, formal documentation (meeting minutes, documentation of operational procedures) and various guides on joining and making most of eduGAIN | GEANT core | |
| Support |
Operational Team tasks
The team
...
Registration and modification of SAML profile related federation information
| information type | security level |
|---|---|
| federation SAML policy URL | 1 |
registration practice statement URL | 1 |
federation SAML metadata aggregate access URL | 3 |
federation metadata signing key | 4 |
| registrationAuthority attribute value | 3 |
Security levels
| security level | description |
|---|---|
| S | special - delegating representatives requires contact with the federation management |
| 1 | informational, not requiring special vetting |
| 2 | important contact information (while not currently used it may be introduced in the future) |
| 3 | information of eduGAIN operational relevance, requires special care |
| 4 | crucial for eduGAIN trust, requires utmost care |
Introduction of new requirements for federation metadata feeds
Metadata requirements have direct operational impact. As described in the [eduGAIN-meta] document, a violation of the requirements results in rejection of a federation feed. The requirements as understood in this documents are the rejection rules implemented in the eduGAIN metadata validator and automatically applied in the aggregation process.
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 in fact not all are just schema errors. Whenever a new problem is reported, the OT makes an assessement whether it inf fact violates a required standard and if so then:
- the OT implements a new validator rule initially as a warning;
- The OT informs the SG about adding a nev validation rule together with an assessement of which federations may be affected by it and suggests a grace period, after which the new rule will start generationg generating an aggregation error;
- 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.
...
When raising an error, the validator points to the specific rule in [eduGAIN-meta].
Arising problems which cause actual interoperability issues need to be handles immediately, as described in the matadata aggregation related procedures section below.
Introduction of new best current practices for federation metadata feeds
...
It must be realised that that the case of all entities supplied by a large federation being deleted form 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 ir it MUST immediately notify the eduGAIN SG that such measures have been taken.
...
Organisation and management of services
| Main access host - technical, validator, mds | |
|---|---|
| DNS names | www.edugian.org, technical.edugain.org; validator.edugain.org; mds.edugain.org All these are CNAMEs for massonia.man.poznan.pl |
| Function |
|
eduGAIN database - edugain-db | |
| Function | store all data for services directly managed by the eduGAIN OT |
| The aggregation host - mds-feed | |
| Function | acquire and validate federation metadata feeds, create, sign and publish the eduGAIN metadata aggregate. |
Security considerations
The security of the eduGAIN SAML services is essentially the security of the eduGAIN aggregate. This in turn depends on:
- validation of federation metadata input data - their originality and integrity - this depends on the safety of federation certificates (stored in the database) and the safety of the signature verification process itself
- aggregation process - it is crucial that the resulting aggregate contains exactly the data provided by participating federations (after modifications described in the [aggregationeduGAIN-meta])
- aggregation signature - the eduGAIN signing key and the signing process are the key factors here.
In order to maintain the high security standards the following operational procedures are in place,
- The edugain-db and mds-feed hosts are located in a secured private network and can be accessed only form 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 form the external network. The resulting signed aggregate is then moved th the distribution host as described in the Metadata aggregation related procedures section.