Table of Contents
SAML metadata about SPF SPs: distribution to identity federations by ERIC
This page provides a status overview of the SP metadata distribution across the various CLARIN SPF identity federations. It is still under construction (October 2017) so some information might be missing or incomplete. If you are looking for the old matrix page you can find it here but keep in mind that the whole metadata workflow changed once the SPF infrastructure was dockerized and the SP metadata file moved from the CLARIN SVN to github. A detailed description of the new workflow can be found in the service provider federation page.
Service Providers in the production SPF
This means the SP entityID is whitelisted. Only the SPs that are whitelisted, will be filtered and passed on to the production SAML metadata. In order to be whitelisted an SP needs to have signed the SPF agreement.
All Service Providers in the production SPF will be registered directly in DFN-AAI (DE), Belnet (BE), Haka (FI), eduID.cz, SURFconext (NL) and via eduGAIN in the various other national federations.
Accepted
See the centre registry SPF page, all the SPs with a checked "Prod?" column.
Current distribution to national federations
Please note: for the other countries we use the eduGAIN metadata distribution. Therefore they are not listed in the distribution matrix.
For an explanation about why this dual distribution mechanism is in use, please see the opt-in page.
Procedure for changing/adding and distributing new SAML metadata about SPF SPs
Adding a new SP or changing SAML metadata about an existing one and distributing it is a complicated procedure.
- Check for pull requests in the CLARIN SPF metadata repository on GitHub. Emails are automatically sent by GitHub when a new pull request is created.
- Make sure the pull request is as marked XSD valid by Travis CI. This is visible on the pull request page a couple of minutes after it is created.
- Merge the pull request into the master branch and wait for Travis CI to generate the QA report visible in this table.
- Make sure the QA report does not present any issue marked in red concerning the SP in question. Follow up with the committers (i.e., SP operators) on whether their submissions meet the guidelines based on e.g. this sheet.
- Create a pull request from the master to the production branch and merge it.
- Cron job 1 running under the spf-cron user on the docker clarin_spf_pipelines_1 image deployed at clarin-vps5, will update the SAML metadata batch at https://infra.clarin.eu/aai/md_about_spf_sps.xml. The CLARIN IdP will use this preproduction batch.
- Organize login tests for every new SP using the CLARIN IdP.
- Mark every new SP entity as production SP. Do this by adding the SP's entity ID to the list in the relevant job definition file on GitHub.
- Cron job 1 running under the spf-cron user on the docker clarin_spf_pipelines_1 image deployed at clarin-vps5, will update the SAML metadata batches under https://infra.clarin.eu/aai/ (this time, including prod_md_about_spf_sps.xml).
- To help everyone track new SPs and their registration statuses across identity federations, add the SPs to the Centre Registry.
- Cronjob 2 running under spf-cron user on the docker clarin_spf_pipelines_1 image deployed at clarin-vps5, will use the information in the Centre Registry to analyze the SAML metadata batches under https://infra.clarin.eu/aai/ into useful pieces under https://infra.clarin.eu/aai/sps_at_identity_federations/.
- DFN-AAI will pick up the mutations to SAML metadata batch. This will ensure that it is distributed throughout eduGAIN, and reviewed additionally by DFN-AAI.
- Once DFN-AAI has picked up the new SP (and thus the SP is in eduGAIN) which you can determine via the Centre Registry, add the SP to further identity federations. Click on the country code columns in the above table for details on the identity federation-specific procedure.
- Finally, check whether any new SP has been registered for multiple identity federations using this eduGAIN webapp (i.e., a clash). In case a clash is found, request the SP operator to remove the registration with any federation other than the CLARIN SPF.
Issues with production SPs
Please avoid expiring SAML signing certificates by doing a certificate roll-over on time.
Current SPs with expired certificates:
- http://www.clarin-pl.eu/shibboleth
- https://clarino.uib.no/
- http://sp.lat.csc.fi
- https://clarin.fz-juelich.de/shibboleth
- https://asvsp.informatik.uni-leipzig.de/
- https://beta-catalog.clarin.eu/sp/shibboleth
Remedy: create new SAML metadata, sign with a valid certificate (could be self-signed)
