Moving from an OpenAthens IdP to a Shibboleth IdP

Many institutions, on first joining the UK federation, handle their identity provision requirements by purchasing an OpenAthens subscription from Eduserv.

After using an OpenAthens IdP for a year or two, such an institution may decide to move on to implementing its own Shibboleth IdP, and switching the identity provision for its users to it.

The following notes are intended to assist institutions considering such a transition.

Setting the scene

Suppose that at present staff and students of Loamshire College are using an OpenAthens IdP to access content in the federation. For most services, they select "Loamshire College" from the federation WAYF's menu and then authenticate with their Athens credentials.

However, Loamshire College has just implemented its own Shibboleth 2.x Identity Provider. (See entity registration for details of how to do this.) The College intends to switch its identity provision to the new IdP once it has been tested.

Once the new IdP has been configured, tested and put into service, from a user's point of view it will work in a similar manner to that of the OpenAthens IdP, although on selecting it from the WAYF menu users will be taken to Loamshire College's own sign-on page and they will authenticate with their College credentials.

Recommended approach

Having both the OpenAthens IdP and the College's new IdP visible at the same time in the WAYF would be confusing for users. It is better to have only the IdP which is currently providing service visible in the WAYF. Thus, while the new IdP is under development it should be hidden from the WAYF, until it is ready to go into service. At this point it should be made visible and the OpenAthens IdP hidden.

To achieve this it is recommended that one should specify the visibility of a replacement IdP as "No" when registering it with the federation, which hides it from the WAYF during its test phase; it can be made visible later.

Another point to consider is the name of an Identity Provider as it appears in the federation WAYF; this is known technically as its "Organization Display Name". Such a name must be unique within the federation, and this requirement applies whether or not an IdP is hidden from the WAYF.

Given these conditions, one way for Loamshire College to proceed is as follows:

  1. Specify the Organization Display Name of its new IdP as "Loamshire College (Shibboleth Testing)" or similar, and specify its visibility as 'No'.
  2. When the testing period is finished, ask the federation to change the Organization Display Name of the OpenAthens IdP to "Loamshire College (Athens)", say, and the new IdP to "Loamshire College". At the same time ask for the OpenAthens IdP to be hidden from the WAYF and the new IdP made visible.

By this means, users from the College will only ever see "Loamshire College" in the WAYF menu, although the IdP which it represents has been changed behind the scenes.

Testing the new IdP

How does one test an IdP which is hidden from the WAYF?

The following federation pages 

  https://target.iay.org.uk/secure/printenv.cgi (Shibboleth 1.3 test SP)
  https://sh2testsp1.iay.org.uk/secure/printenv.cgi (Shibboleth 2.x test SP)

can be used for testing. As they use an 'unfiltered' WAYF, that is one which displays all IdPs in the federation, including those hidden from the standard federation WAYF, it is possible to select your new IdP. The output from these pages give details, among other things, of the attributes released by the IdP, and are extremely helpful in diagnosing whether the IdP is performing correctly.

Another approach to selecting a hidden IdP is to invoke a federation service which makes use of the federation WAYF, and then when the WAYF appears, instead of selecting an IdP from the menu edit the WAYF URL in the bar at the top of your browser such that 

  https://wayf.ukfederation.org.uk/shibboleth-wayf/uk.wayf?...

becomes 

  https://wayf.ukfederation.org.uk/shibboleth-wayf/ukfull.wayf?...

This effectively switches to use of the 'unfiltered' WAYF, and the new IdP can then be selected. However, please do not test a raw IdP against an actual live service, unless you have agreed this with the SP maintainers – a misconfigured IdP may cause problems for some SPs.

Keeping your users informed

When you have finished testing, you need to prepare your users for the transition.

Most service providers use the eduPersonTargetedID attribute, generated from the user's identity and the IdP's entityID, to handle personal customisation and storage of specific information, such as saved links or searches. When you switch identity provision to your new IdP, your users' eduPersonTargetedID attribute values will inevitably change, and it follows 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.

You are advised to give your users as much advance notice as you can of this change. They should take a note of service personalisations, saved searches, etc. that they have made, and then restore the settings once they are able to access the services in question via the new IdP when it comes into service.

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 WAYFs, 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
OpenAthens IdP in use: not hidden, Organization Display Name of "Loamshire College".
Stage 1
Contact the UK federation helpdesk and ask to register your new Shibboleth 2.x IdP: to be hidden from the WAYF, and given an Organization Display Name of "Loamshire College (Shibboleth Testing)" or similar. When it is registered, start testing the IdP within the federation.
Stage 2
Check with your SPs to find out whether any of them will need to be informed about the change.
Stage 3
Warn your users about the change: give them the opportunity to record the information which they have saved at SPs.
Stage 4
When you have completed testing of the new IdP, inform any SPs who need to know about the change (as determined at Stage 2).
Stage 5
Ask the UK federation helpdesk to switch the visibilities of the OpenAthens IdP and your new IdP, and change the Organization Display Names to "Loamshire College (Athens)" and "Loamshire College".
Stage 6
Once you are satisfied that your new IdP is performing satisfactorily, ask the UK federation helpdesk to delete your OpenAthens IdP.

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