Configuring the Shibboleth Identity Provider

The configuration for the Identity Provider, as it concerns an administrator, can be listed in four parts. Most of the configuration can be copied from the existing configuration for the test installation (and changes described in this section are relative to this rather than to the details in the unconfigured installation), and requirements for change are indicated. (Note that simple changes for file locations are not listed in this section, and it makes sense to set up Shibboleth so that the configuration files can be accessed from a simple location such as /etc/shibboleth; this can be done with a soft link to the actual configuration directory.)

Note that Shibboleth is sensitive to errors in editing these files, and errors in the XML are often hard to find due to their complexity. Before beginning an edit, make sure that the existing version of the file has been saved as backup.

idp.xml

• IdPConfig tag: the AAUrl and ProviderID attributes need to have their hostname updated
• If filenames which reflect the hostname have been used for the key/certificate pair listed in the Credentials section, then these will need to be updated

resolver.xml

You may wish to use a userID created for the purpose to access an LDAP directory to obtain attributes for users; this has the advantage that its privileges can be lower than a real user's (not allowing write access, for example). You will need to change the properties "java.naming.security.principal" (userid) and "java.naming.security.credentials" (password) in the JNDIDirectoryDataConnector element of the resolver configuration file (assuming that you are using LDAP) if you wish to do this and the test system has been configured otherwise.

ARP configuration

This should not need to be changed.

Trust (federation) metadata configuration

The first decision that needs to be made is whether or not all the existing federations should continue to be supported (it is quite possible to keep the test Identity Provider running, and use it for federations which are not supported on the new, main system). Exactly how this is done will depend on the way that the federation involved is set up, but basically what needs to happen is that the metadata of the federation WAYF, the Identity Provider and all Service Providers need to be updated to reflect the move; this will include information about certificates as the Service Providers need to recognise the new Identity Provider's certificate.

It is suggested that it would be sensible to use a simple peer to peer agreement which is with a local Service Provider to test out moving the metadata, to make sure that everything is correctly updated. For other federations, it is best to follow their guidelines, where these exist, or contact the federation management directly. For details of LSE Federations, see LseFederations .

In the metadata file, you need first to locate the entry describing the test Identity Provider. This can most easily be done by looking for the domain of the institution owning the provider in the existing metadata file. There are two types of entry in a metadata file, covering Identity Providers and Service Providers, and to be sure that the Identity Provider entry has been found, look for an AttributeAuthorityDescriptor element in the EntityDescriptor element that encapsulates the entry. The items that will need changing are the following:

• The KeyName needs to be updated to match the CN of the certificate to be used to sign data
• The Location attribute for the SingleSignOnService needs to be updated to the new Identity Provider Handle Server URL
• The Location attribute for the AttributeService needs to be updated to the new Identity Provider Attribute Authority URL
• The information held in the Contact tags will probably need to be updated

The final part of the procedure for adding a trust relationship to an Identity Provider is to add trusted certificates to the directory configured in the web server configuration for the Attribute Authority (the virtual host to run on port 8443). This needs to have copies of the certificates used to validate certificates presented by Service Providers (and these should already be installed in the equivalent directory for the test installation). For Apache to register the certificates as trusted, it is necessary to create symbolic links to the certificate files named by the hashed value of the certificate; with a RedHat ? installation, there is a useful Makefile in the Apache ssl.crt directory which will register all the certificate (.crt) files in the directory just by typing "make" at the prompt.

Simon McLeish - 07 Oct 2005