...
Operational Team procedures
Registration and modification of SAML profile related federation information
| information typeregistration level | security level | ||||
|---|---|---|---|---|---|
federation delegate to eduGAIN SG | eduGAIN | S | |||
| federation delegate deputy to eduGAIN SG | eduGAIN | S | |||
| federation page URL | eduGAIN | 1||||
| federation mail contact | eduGAIN | 2 | federation SAML policy URL | SAML | 1 |
registration practice statement URL | SAML | 1 | |||
federation SAML metadata aggregate access URL | SAML | 3 | |||
federation metadata signing key | SAML | 4 | |||
| registrationAuthority attribute value | SAML | 3 |
...
| 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 |
...
- 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 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 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.
...
For security reasons singing keys can be present only for federations which have been approved to be a member of the eduGAIN SAML Profile.Profile.
eduGAIN Metadata Distribution Service (MDS)
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 the . In order to minimise risks of exposing high permissions account on the mdsh host the resulting aggreagate file is transferred to the mds host using a dedicated low premissions account. The aggregate is then moved to the finel place on the mds host in a process innitiated within the mds host.
Organisation and management of services
...