Joining SDSS as an Identity Provider Site
Note that the SDSS Federation no longer accepts new applications to join. Applications should instead be made to join the UK Federation. The information on this page is of historical interest only.
To apply to join the SDSS Federation as an Identity Provider site, e-mail edina@ed.ac.uk (the EDINA helpdesk) and ask for your message to be forwarded to the SDSS team. In the e-mail, please include the following, which includes all the information we will need to put in your <EntityDescriptor> entry in the federation metadata (see http://sdss.ac.uk/fed/sdss-metadata.xml for examples):
- Provider type: State that you are applying to be an Identity Provider.
- Policy: A brief statement agreeing to operate in accordance with the SDSSFederationPolicy.
- Alias: A short name (a few words at most) to identify your site. This is the text which will appear in the WAYF list of Identity Providers.
- Technical contact: A technical contact name and Email address. The technical contact serves as the primary point of contact for all technical issues for the organisation participating in the SDSS federation, and communicates with the SDSS Federation technical staff to ensure smooth operation of the federation's infrastructure.
- Administrative contact: An optional administrative contact name and Email address (if different from the technical contact). The administrative contact serves as the primary registrar and administrator of the organisation's SDSS federation participation. The administrative contact is responsible for registering and maintaining technical aspects of the organisation's participation in SDSS, including Identity Provider information, metadata, and technical contact information. If no administrative contact information is provided, the technical contact will be used instead.
- Support contact: An optional support contact name and Email address. The support contact is the primary contact for error handling. It may be a helpdesk or a designated support person. If no support contact information is provided, the technical contact will be used instead.
- Entity ID: This must be a URI identifying your identity provider. If your identity provider is already a member of any other federation then please give its existing entity ID, even if it appears to be federation-specific. If your identity provider is not already a member of another federation, please consult EntityIDPolicy for details of the process of constructing a new entity ID.
- SSO Service Location: The URL of your Shibboleth SSO service, e.g., https://shibbox.uni.ac.uk/shibboleth-idp/SSO. Note that port numbers other than the default (80 for http, 443 for https), while allowed, may cause problems for end users behind outgoing firewalls.
- SSO Service Name: The Common Name from the SSO service's certificate. In most cases, this will be the fully qualified domain name of the SSO service, e.g., shibbox.uni.ac.uk.
- Artifact Resolution Service Location: Optionally, the URL of your Shibboleth artifact resolution service, e.g., https://shibbox.uni.ac.uk/shibboleth-idp/Artifact. Note that port numbers other than the default (80 for http, 443 for https), while allowed, may cause problems for end users behind outgoing firewalls.
- AA Location: The URL of your Shibboleth attribute authority server, e.g., https://shibbox.uni.ac.uk/shibboleth-idp/AA. The same port number considerations apply as for the SSO service.
- AA Name: The Common Name from the attribute authority's certificate. Again, this will usually be the fully qualified domain name of the attribute authority server, e.g., shibbox.uni.ac.uk. Note that if the Common Names are the same, it is possible to use the same certificate for the SSO service and the attribute authority.
- Domain: The domains (scopes) for which attribute assertions made by this identity provider should be considered valid. Normally there will be only one of these and it will be either the fully-qualified domain name of the server machine (shibbox.uni.ac.uk) or, for institutional IdPs, the institution's DNS domain (uni.ac.uk).
- OrganizationURL: The URL of a web page providing a description of the organization applying to join the federation.
We will let you know by e-mail once the SDSS Federation metadata has been updated to include the information you supplied. You will then need to download the new metadata and modify your Shibboleth configuration to match it, as described at SetupIdP.
Institutional Domains
If you are applying to become the Identity Provider for any organisation with a scope or lifetime greater than a short-term project group, you must additionally send us a hard-copy letter on the organisation's letterhead, agreeing to abide by the SDSSFederationPolicy. The letter should either refer to or follow the wording of that policy web page and be signed by a senior person who is authorised to make legally binding commitments on behalf of the organisation. This applies, for example, to whole institutions (ed.ac.uk, ox.ac.uk), departments (dcs.ed.ac.uk, oucs.ox.ac.uk) and quasi-independent entities whose members are not necessarily members of their hosting institution (edina.ac.uk).
This requirement gives service providers a level of assurance that identity providers will only provide credentials to members of their own organisation that is at least as strong as existing identity mechanisms (Athens, IP address checking). It therefore allows SDSS service providers to use a Shibboleth attribute such as member@gla.ac.uk to grant access to existing JISC information environment resources licensed to "all members of the University of Glasgow", without requiring contract renegotiation with the content provider.
Please send the letter to:
Alternatively, you may fax the letter, marked for the attention of the SDSS team, to: