Migration guidance
When moving users from one IdP application to another, it's important for the transfer to be as seamless as possible. The two main causes of disruption are loss of personalisation caused by changes in the value of eduPersonTargetedID (more precisely, the hash value generated from the user credential, salt and the entityID of the SP involved) and failure of direct links to online content due to the failure of WAYFless URLs.
Preservation of eduPersonTargetedID
Migrating from OALA
You may run into difficulties if your IdP releases eduPersonTargetedID as a scoped string within SAML2.
eduPersonTargetedIDis a SAML2 Persistent Name Identifier sent as a SAML attribute callededuPersonTargetedIDorurn:oid:1.3.6.1.4.1.5923.1.1.1.10
Migrating from Shibboleth
eduPersonTargetedID is a SAML2 Persistent Name Identifier sent as a SAML attribute called eduPersonTargetedID or urn:oid:1.3.6.1.4.1.5923.1.1.1.10, you should check the values generated for this are consistent before, during and after migration.
WAYFless URLs
Changes to your IdP can result in a need to replace WAYFless URLs used to provide convenient links to SPs' online resources without having to go through the central discovery service, 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.
You might be able to use the UK federation WAYFless URL generator post-migration to create some new WAYFLess URLs
The URLs to lookout for and work to replace are typically "IdP first", they will reference your IdPs hostname e.g. https://idp.example.ac.uk and then followed by a path being similar to either idp/profile/Shibboleth/SSO?shire= or idp/profile/SAML2/Unsolicited/SSO?providerId=, then followed by either a URL relating to the SP such as AssertionConsumerService Location or an entityID
If you would like further guidance on this please contact us.