Document structure
OT tasks
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
Service Order
Problem resolution
Configuration change
System update
Backup
Disaster recovery
eduGAIN OT directly manages ...
eduGAIN OT supervises ...
information type | registration 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 |
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 prifile.
security level | description |
---|---|
S | special - delegating representatives requires contact with the federation management |
1 | informational, not requiring special vetting |
2 | important contact information |
3 | information of eduGAIN operational relevance, requires special care |
4 | crucial for eduGAIN trust, requires utmost care |
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, even if it is in fact a standards violation, it is first raised to the eduGAIN SG. In the same time, eduGAIN OT contacts federations whose metadata feeds cause the problem and points out that the error should be rectified. After the SG has decided that a new requirements should be implemented and a suitable grace period is set, the new validator rule is implemented by the eduGAIN OT, initially as a warning and after the agreed grace period has passed, as an error.
Every rule is documented in the [eduGAIN-meta]
When raising an error, the validator points to the specific rule in [eduGAIN-meta]
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].
All virtual machines running eduGAIN services are regularly updated.
Before an update is planned, the local personel at PSNC is notified in case
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:
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 list.
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 MUST immediately notify the eduGAIN SG that such measures have been taken.
One example of such a special situation may be a real case of an introduction of a valid but a very short-lived metadata file followed by a metadata error causing a aggregation reject. That situation, leaving no time for normal procedures to take place, was caused by a configuration error on the federation side and was rectified in a short time while the eduGAIN aggregation was suspended.
The eduGAIN database is central to all eduGAIN core services. The database stores:
The database is placed on a host separated from the external network, accessible only trough a limited numbers of secure hosts. Database access is realised via dedicated user accounts with access right crafted to minimize the possibility of unauthorized changes.
The database is managed mostly via a web interface secured with access passwords. Modification of data on security levels S, 1, 2 can be done without any additional protection. Management of data with security level 3 is protected with on-time passwords mailed to an external mail account of the managing administrator. Management of data with security level 4 requires direct access to the database host.
For security reasons singing keys can be present only for federations which have been approved to be a member of the eduGAIN SAML Profile.
Under the term services listed are utilities as perceived by external users. The internal organisation of services, flow of information and dependencies are not important in this view, but are described in sections further down.
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. |
the technical site | https://technical.edugain.org | The technical site directed primarily at the federation level personel. It provides information about eduGAIN members, details about their participation. The technical site is also the distribution point of documentation and home for several core and supplementary services. |
validator | https://validator.edugain.org | The eduGAIN validator is a service designed for validating metadata adherence. The software has been created primarily as a component of the eduGAIN metadata aggregation and the details of validation rules are given im [eduGAIN-meta]. The same software enriched by a GUI is used a a tool form manual validation of metadata and serves as a support tool for federation operators. |
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 to 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 signed by federations, direct links to metadata validation |
entities database GUI | http://technical.edugain.org/enties | This service is an interface to the part |
eduGAIN database API | ||
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
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. |
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. |
All eduGAIN core service hosts are
Custom eduGAIN software
The security of the eduGAIN SAML services is essentially the security of the eduGAIN aggregate. This in turn depends on: