Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Operational Team procedures

Registration and modification of SAML profile related federation information

information typeregistration levelsecurity level
federation delegate to eduGAIN SGeduGAIN

S

federation delegate deputy to eduGAIN SGeduGAINS
federation page URLeduGAIN1
federation mail contacteduGAIN2
federation SAML policy URLSAML1

registration practice statement URL

SAML1

federation SAML metadata aggregate access URL

SAML3

federation metadata signing key

SAML4
registrationAuthority attribute valueSAML3

Federation delegate and deputy are the only federation representatives authorized to submit information, therefore their identity needs to be established in a trusted way, this is however part of the global eduGAIN trust model, not specific to the SAML profile.


Security levels
security leveldescription
Sspecial - delegating representatives requires contact with the federation management
1informational, not requiring special vetting
2important contact information (while not currently used it may be introduced in the future)
3information of eduGAIN operational relevance, requires special care
4crucial 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.

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

...