Preparation

Before you start you should review this documentation and make your decisions about platform and supporting software.

  • Make any necessary changes to firewall rules as set out in the firewall rules section
  • Acquire a browser-facing certificate according to the advice in the browser-facing certificate section. Create a keystore file as part of this process, unless you plan to proxy through Apache httpd

You will need to have the following information ready:

  • the FQDN a.k.a. DNS hostname of the IdP; this should be something well-chosen and stable, that reflects the function eg. idp.example.ac.uk, and not the physical name of a server that may change, because it will be used to generate the IdP's metadata. Make sure it is set up in the DNS before you start.
  • the scope that your IdP will assert; this is normally your organisation's DNS domain name eg. example.ac.uk. The domain in the scope must verifiably be owned by your organisation and comply with our Metadata Registration Practice Statement.
  • the entityID you plan to use for your IdP. You can usually accept the entityID created by the Shibboleth installer, which it bases on the hostname, but you must check it and make sure it is suitable; you can override its choice at installation time. It must be an https URL based on a domain name verifiably owned by your organisation, and must comply with our entityID policy and our Metadata Registration Practice Statement. It should be concise and descriptive, eg. https://idp.example.ac.uk/idp. It must be unique and not already registered in the UK federation.
  • your LDAP or Active Directory domain name eg. ad.example.ac.uk
  • the username and password of a service account that can be used to access the LDAP or Active Directory; this should not be the account of a real person. The account should have minimal privileges; in Active Directory it should be a member of Domain Guests only, and in the account Properties it should have:
    • 'User cannot change Password' ticked
    • 'Password never expires' ticked
    • 'User must change password at next logon' should be not be ticked
    • Account Expires: Never
  • if using another LDAP directory then the service account should have equivalent properties configured as those described above for Active Directory