Changes to the Requirements for SAML2 Service Providers that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on ….

The following describes the technical and administrative checks that will be made before a service provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for service provider operators for assessing their readiness to participate.

Metadata

• MUST¹ have an entityID that is a URL (well-known location). The URL SHOULD use the https scheme and it is RECOMMENDED that valid metadata be available at this URL.
• MUST use secure (https) end-points for any <md:AssertionConsumerService>, <md:SingleLogoutService> or <md:ArtifactResolutionService>.
• MUST contain an <md:Organization> element, where:
  • <md:OrganizationName> MUST reflect the legal name of the juristic person.
  • <md:OrganizationDisplayName> MUST be present adn SHOULD reflect a commonly known or shortened version of the organisation’s name
  • <md:OrganizationURL> MUST contain the organisation’s web site address.
• MUST contain at least one <md:ContactPerson> of contactType="technical" and SHOULD contain one of contactType="support". Where <md:EmailAddress> is given this SHOULD be a role account rather than an individual.
• MUST contain an <mdui:UIInfo>, with at least the following elements set:
  • <mdui:DisplayName> — meaningful name for service.
  • <mdui:Description> — short (max 140 chars) explanation of the purpose of the service, such that it is reasonably obvious why the attributes requested are required.
  • <mdui:PrivacyStatementURL> — web site containing a copy of the service provider’s privacy policy.
• It is RECOMMENDED that a <mdui:Logo> be provided. Any logo MUST be either served from a secure (https) server or expressed as a data: URI². Logos SHOULD have an aspect ratio as close to 1:1 as possible and SHOULD be at least 100x100 pixels (although 300x300 is RECOMMENDED).
• SHOULD NOT contain a <mdrpi:RegistrationInfo> element (any existing one SHALL be removed by the federation agregator)
• MUST contain <md:RequestedAttribute> entries.
• SAML certificates included in metadata SHOULD be self-signed.
• web server certificates used for end-points MUST use PKI that is reasonably likely to be embedded in the browser of all users of the service. Unless an explanation is provided, these SHALL be tested against the root CA lists of common browsers.

Language and Localisation

The SAML metadata specification allows display elements such as <md:OrganizationName> to be localised by using the xml:lang attribute to specify a BCP 47 language code. In common with other federations worldwide, English (xml:lang="en") MUST always be included and will be used as the default when no localised version is available.

It is strongly RECOMMENDED that official translations of organisation, display, or service names be included in metadata. In particular, major South African languages such as isiZulu (zu), isiXhosa (xh) and/or Afrikaans (af) are encouraged.

Technical

• Clocks MUST must be synchronised via the Network Time Protocol (NTP; SNTP) or equivalent such that they ultimately derive their time from the South African master clock maintained by National Metrology Institute of South Africa or an acceptable alternative (e.g. za.pool.ntp.org).
• Logs of successful authentications MUST be retained for at least 184 days.
• Federation metadata SHOULD be refreshed at least once per day and MUST be refreshed at least once per cacheDuration.

Administrative

• Participants that are not already signatories of the REN Service Agreement MUST provide documentary proof of legal name, by means of one of the following:
  • CIPC registration certificate;
  • Trust deed;
  • SARS tax clearance certificate;
  • NPO registration; OR
  • Any other mutually acceptable means.
• Participants MUST have signed a Participation Agreement.
• Above paperwork SHOULD only to be completed for the first <md:SPSSODescriptor>. More than one service provider MAY be registered by a given participant, and subsequent ones are assumed to be bound by the same agreement.
• Each entity must be accompanied by a separate registration request form.

For each <md:SPSSODescriptor>, MUST come to an agreement on:

• Statement of purpose to be reflected in <mdui:Description>.
• Attribute release policy to be reflected as <md:RequestedAttribute> — note that per the principle of minimality, requested attributes MUST be adequate, relevant, and not excessive.
• Whether the entity meets the requirements for research and scholarship.
• Whether the entity should be published into inter-federation metadata (opt-in).