You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Metadata Processing Instructions/Checklist

This checklist describes what happens if an SP operator submits metadata during the eduGAIN Easy SP Registration workflow using the UK Access Management Federation as federation of last resort.

Process Overview

The process starts for the eduGAIN Support team with a registration request that is submitted by an SP administrator on the web page How to Join eduGAIN as Service Provider. The content of the metadata registration form then is submitted to the mailing list simplified-registration@lists.geant.org and from there to support@edugain.org. From this point on the goal of the eduGAIN Support team should:

  1. Check the submitted metadata and contact details using the check list below
  2. Enquire SP admin about missing/unclear aspects of registration request if needed
  3. Forward the validated metadata to the UK Access Mangement Helpdesk (service@ukfederation.org.uk) via email with the template Email in Appendix A1 to include it in their federation metadata and eduGAIN. It is assumed that at this point the SP administrator already completed applied already for membership in the UK Access Management Federation as described in Step 2 of the Step-by-Step guide. It also is assumed that the Service Provider is correctly configured and fully functional.

To process a registration request, the Service Levels described in Appendix A2 apply as agreed with the UK Access Management Federation.

Checks

When receiving a new SP registration including contact details and metadata as in the form on the Step-by-Step guide, the following checks should be applied:

Legit Registration Check

  • Check if registration is real and plausible.
    • If registration is very likely to be from a (SPAM) bot, ignore it
    • If it is unclear whether the registration is real, ask back

Manual Checks

  • Check if organisation’s name is valid using the domain name of the contact email address to check whether there exists a web page for that domain name (appending www. to domain name). If web page or company name don’t match or are obscure in another way, ask the contact why there is a mismatch.
  • Check whether entityID does already exists in eduGAIN (using MET: http://met.refeds.org/) If it already exists, inform the contact that his SP is already published in eduGAIN via federation XY. Therefore, no additional registration of this SP is needed. (This step could also be automated and built into the metadata submission form in case there would be many SP registrations)
  • Check that the submitter owns the email address they entered by sending a verification email ( can be automated later on )

Metadata Checks

The goal of these checks are to ensure that submitted metadata is valid and to ensure that it also contains all the required elements plus ideally the optional elements from the eduGAIN Metadata Profile

  • Use an XML validation tool to ensure that metadata is well-formed and valid according to the used SAML2 schemas. The metadata should be checked using all SAML2-related namespaces/schemas listed in Appendix A3. One could use the SAML tools provided here (https://code.geant.net/stash/users/switch.haemmerle/repos/saml-tools/browse/xml-validation) or use for example XMLSPear, an OpenSource Java-based XML manipulation tool.
  • Open the service’s URL (e.g. using the URL used in one of the AssertionConsumerURLs) to open the service’s web page and check if the service is running and providing more or less what the service’s name and description imply
  • See if the service has the REFEDS Research & Scholarship (R&S) entity category set.
    • If the category is set, leave it up to the UKAMF helpdesk to validate if the requirements are met
    • If the category is not set, judge yourself using the criteria (section 4) of https://refeds.org/category/research-and-scholarship if the R&S entity category would be applicable for this SP. If so, change metadata to include this.
  • Ensure that if possible everything is present in metadata that SHOULD be there (with the exception of the mdrpi:RegistrationInfo element) according to the eduGAIN Metadata Profile http://services.geant.net/edugain/Resources/Pages/Home.aspx If something is missing try to enrich it using public information from the service’s web page (e.g. service name and information from the “About” page of the service). Use Rich SP metadata example as guideline what metadata could/should include.
  • Ensure that there is at least one <RequesteAttribute> element in metadata. If this is not the case, ask Contact person what attributes they need for service and add them if reasonable.

ToDos and Future developments for Registration Form

This section contains ToDo’s and future improvements. The latter are features to implement only if there is a need or request for them.

ToDos

  • JavaScript-Captcha to prevent bots sumitting form

Future improvements

  • Add samlmetajs to check SAML metadata and show a warning in case of invalid metadata but still allow submission of the form.

Appendix

A1. Mail template to forward registration after successful check

Mail to: service@ukfederation.org.uk

Subject: New eduGAIN registration for

Body:

Dear UK Access Management service desk

The eduGAIN Support team has received a request to register the following service as eduGAIN service via the UK Access Management federation. We have done some preliminary precheck of the SAML2 metadata and kindly ask you to guide the contact person (details provided below) through your registration process. Please keep support@edugain.org also in the loop.

Conctact details:

<insert contact details here>

Metadata:

(is attached to mail)


Best regards

eduGAIN Support Team

A2. SLA and Metrics

The following Service Level Agreement (SLA) and Metrics were agreed with the UK Federation: The following Service Level Agreement is applicable during the pilot:

  • Availability of service infrastructure (metadata aggregate MDA and the Central Discovery Service CDS): target is 99.5% (excluding service-affecting maintenance, which is capped at 0.5%)
  • Reponse time of all email enquiries (time till an automated ticket number is issued): target is 4 hours
  • Respone time of all email enquiries till a reply is sent: 2 working days
  • Membership applications processing time once all required information has been received: target is 5 working days (due to the fact that membership application from some SPs might be complicated)
  • Time till registered UK Access Management Federation SPs are recorded in the UK Access Management Federation and eduGAIN: target is 2 working days During the pilot data for the above metrics should be collected to evaluate and tune the SLA if necessary.

A3. Schema/Namespaces to check against

  • No labels