Moving from one IdP platform to another.

For various reasons, organisations may wish to switch their identity provision from one application to another

The following notes are intended to assist in planning such a transition.

Loss of personalisation - a warning

Most service providers use the eduPersonTargetedID attribute, which the IdP generates from the user's identity, the IdP's entityID and an arbitrary text string, or salt, to handle personal customisation and storage of specific information, such as saved links or searches, as well as user's registration information.

When you switch identity provision, changing any of the above factors will cause your users' eduPersonTargetedID attribute values to change, and it follows from this that users will no longer have access to their previous personalisations or stored content on some services, and they may have to re-register for others. The consequences here can range from the mildly inconvenient to the potential loss of years of work. It's therefore important to keep the entityID, salt and user credentials the same when moving from the old IdP application to the new one.

WAYFless URLs

The term "WAYFless URL" describes a link that your users can follow to an online resource without needing to go through a discovery service to select their organisation. These links can go either to a resource's home page or to specific content on the site ("deep links").

Changing to an IdP with a different entityID, or located on a different server, can result in a need to replace pre-existing WAYFless URLs linking to SPs' online resources, so any such links on portal pages or in your library's online indexes will need to be replaced. Further, some SPs' own discovery services are based around WAYFless URLs, and you may need to contact these SPs to ensure a smooth transfer of service.

Suggested procedure

Suppose that Loamshire College have been using a particular IdP application for some years, and they then decide to move to another one. How best to move forward with the least possible disruption to their users?

At present staff and students of Loamshire College use their IdP to access content in the UK federation either by visiting content providers' websites, clicking through to a discovery service selecting "Loamshire College", or by following a link to a particular provider from a library index or portal page. Either path will lead them to a login page where they can authenticate with their own local institutional credentials and access their desired service.

Ideally, on moving from one IdP application to another, the college's users should not notice a thing - except, perhaps, cosmetic changes to the login page.

Recommended approach

As the new IdP needs to be tested before it can be deployed, the best approach is to register it as a test IdP with an amended entityID.

Having both old and new IdPs visible at the same time in the discovery service could be confusing for users. It is better for only the IdP which is currently providing service to be visible. So the new IdP should be registered in the UK federation with visibility "No", and kept invisible while under development. As not all SPs honour the Hide From Discovery entity category, and display names must in any case be unique, the new IdP should have a display name such as "Loamshire College (Testing - do not use)"

When configuring the new IdP, ensure that it has the same user credential as the old IdP and that the same salt is used for generating the eduPersonTargetedID value as in the old IdP.

Testing the new IdP

Initial testing of the new IdP should be carried out with the UK federation test SP

Please do not test a newly-registered IdP against an actual live service, unless you have agreed this with the SP maintainers – a misconfigured IdP may cause problems for some SPs.

Informing your service providers

Some service providers will automatically detect your new Shibboleth IdP when it is made visible and it will appear in their discovery services, whereas others will need to be informed that you wish to start using the new IdP. It is advisable to check this in advance by contacting your service providers directly.

Summary

In summary, the stages go something like this:

Stage 0: Original IdP in use: not hidden, Organization Display Name of "Loamshire College". Record values of eduPersonTargetedID released to UK federation test SP on behalf of sample users.
Stage 1: Register your new IdP under a temporary entityID: to be marked as hidden from discovery, and given an Organization Display Name of "Loamshire College (Testing - do not use)" or similar. When it is registered, start testing the new IdP within the UK federation, and with the UK federation's test SP in particular.
Stage 2: Check with your SPs to find out whether any of them will need to be informed about the change - let them know that while you will be changing your IdP application and endpoint locations, your scope and entityID will not be changing.
Stage 3: When you have completed testing of the new IdP (including ensuring that eduPersonTargetedID hash values haven't changed), inform any SPs who need to know about the change (as determined at Stage 2).
Stage 4: Ask the UK federation helpdesk to update your new IdP's metadata with the original entityID and Organization Display Name and publish it in place of the old IdP's metadata and delete the new registration.
Stage 5: Amend the new IdP's configuration to use the original entityID and keep both IdPs running.
Stage 6: As the new metadata propagates to the SPs in the federation, the old IdP will see less usage and the new IdP more. Once you are happy that the new IdP is performing satisfactorily, and there are no longer any hits on the old one, switch off your old IdP.

The UK federation helpdesk can provide support throughout this process; just ask.