Registering a Shibboleth Identity Provider

You must register your Shibboleth IdP's metadata with us in order to interoperate with other entities in the UK federation. You may need to configure more features once your IdP is registered, for example to configure and test attribute release policies.

The UK federation implements a policy of exporting all entities to eduGAIN (with some exceptions). More details concerning this can be found here:


Before sending the information required for registration, listed below, you must ensure the following:

  • You have installed and configured the Shibboleth IdP software.
  • You have obtained a browser-facing certificate and configured it for port 443 of your IdP. The UK federation does not need to know about this browser-facing certificate.
  • Your organization controls the domain in the entityID and scopes associated with your IdP
  • You may need to edit the IdP's automatically-generated metadata, although typically you will not need to do this at install time. The metadata is stored in %{idp.home}/metadata/idp-metadata.xml. It is created when the installation script is run and not subsequently updated. This means that if you make changes to your IdP's configuration, you should also add the corresponding changes manually into the idp-metadata.xml file. Some examples of changes are: you may need to change the entityID from the one automatically generated by the installation script; you may also need to modify the certificate information if you decide not to use the self-signed trust fabric certificate generated during installation; you may want to enable or disable certain profiles.
  • You need to consider how your IdP will appear in discovery services and its visibility. The UK federation CDS (Central Discovery Service) acts as a fallback for SPs that do not want to run their own discovery service. Both the CDS and local discovery services should display the IdP Organization Display Name, and may display the IdP's logo. Please review the federation's IdP listing policy.
  • You have read the UK federation Operational Information page.
  • You are familiar with the UK federation's Technical Recommendations for Participants, and other UK federation service documents.

Registration procedure

Once these prerequisites have been met:

  1. A Management Contact for your organisation must email an IdP registration request to the UK federation Helpdesk and include the information required for registration, listed below.
  2. We will verify this information and perform several technical checks. We may need to communicate with the registrant to rectify any issues.
  3. We then authenticate the trust fabric certificate(s) in the IdP metadata by means of an email-based security procedure (see Certificate verification). The Management Contact must reply to our email before we can complete the registration.
  4. Once we have received the authentication email from the Management Contact, we will publish your IdP's metadata in the UK federation metadata on the next publishing run. Please take note that metadata must propagate to the entities your IdP will interoperate with.
  5. We will let you know by email once the UK federation metadata has been updated to include the information you have supplied.

You should not attempt to gain access to any live service until you have verified that your identity provider is properly configured and handling attributes correctly. You can test your IdP using the UK federation test SP.

Information required for registration

The information required for registration should be provided in the email body of the message as plain text, please do not provide this as an attachment from your office software, if you must provide an attachment please use a text editor.

You can use the following IdP registration request link to create an email message.

  • entityID: The entityID is a URI identifying your identity provider. It must be different from the entityID of any existing identity provider or service provider already in the UK federation. If your identity provider is already a member of another federation please give its existing entityID, even if it appears to be federation-specific. If it is not already a member of another federation, please consult the federation entityID policy.
  • Scopes: The scopes (security domains) for which attribute assertions made by this identity provider should be considered valid. Usually there will be only one of these and it will almost always be the organisation's domain name. This should be specified in lower case.
  • Visibility: Specify "yes" or "no". Please see the federation IdP listing policy for further details. If your organisation already has a registered IdP visible in the default list, we recommend that you register any additional IdP with visibility "no"
  • User accountability: Specify "yes" or "no". This is a declaration whether or not the identity provider commits to observe the provisions of 'user accountability', as defined in section 6 of the federation's Rules of Membership. ("yes" may require extra work by the identity provider operator, "no" will deny your end users access to some services.)
  • Software: (recommended) The SAML product name and software version you have chosen to deploy for your IdP, for example Shibboleth IdP version 3.3.0. This information enables us to gauge appropriate support levels for software in use within the federation, and we do not publish this information.
  • Logo: (recommended) The HTTPS-protected URL of an organizational logo, suitable for display on the CDS. It may also appear on a SP's discovery page when a user requires access. Please see the federation MDUI Recommendations page for more information. Please do not send image files; we do not include image files directly in the metadata.
  • Organisation display name: A short name (a few words at most) to identify your IdP. This is the text which will appear in the CDS list of identity providers. The text selected should comply with these guidelines.
  • Organisation URL: The URL of a web page providing a description of the organisation or organisational unit responsible for operating the identity provider.
  • Support contact: The name and email address of one or more Support contacts. While a Support contact may be an individual, we would now recommend using a generic email address (either shared or a mailing list) with a generic title (such as 'Help desk').
  • Technical contact: The name and email address of one or more Technical contacts. While a Technical contact may be an individual, we would now recommend using a generic email address (either shared or a mailing list) with a generic title (such as 'Help desk').
  • Administrative contact: The name and email address of one or more Administrative contacts. Administrative contacts must be named individuals using unshared email addresses as they have the authority to amend or delete their entity's metadata. (Their names and email addresses are not published in the federation metadata.)
  • Security contact: (recommended) The name and email address for one or more Security contacts.
  • Automatically generated metadata: Further information required for the registration of your IdP is generated by your IdP during the installation process, so please send us the file %{idp.home}/metadata/idp-metadata.xml. You may need to edit this file before sending to us, as described above.

Optional information

  • Sirtfi compliance: If your SP complies with the Sirtfi incident response framework, please indicate that the SP has passed a self-assessment of Sirtfi v1.0. You MUST also provide the name and email address of one or more security contacts for the SP. The email addresses must be reachable from outside your organization. See our Sirtfi documentation page for more information.
  • Research & Scholarship (R&S) entity category support: The UK federation encourages IdP operators to support the REFEDS R&S entity category to facilitate research collaboration. See our REFEDS R&S documentation page for more information.