The Identity Provider (IdP) at our host institution was recently upgraded which unfortunately prevented us logging into our own web site. The following article gives a little detail on the root cause and how we dealt with it.

Shibboleth IdP Upgrades and eduPersonTargetedId

Lots of services in the UK Federation use opaque identifiers for visitors to their web sites to apply personalisations and other user-specific services. This identifier is created by IdPs, who know lots of things about you, such as your name and phone number, and will check your password to authenticate you.

Services in the UK Federation are given this opaque identifier by the IdP. It is known as the eduPersonTargetedId and has the form:

abcdefghijklmnopqrstuvwxyz@example.ac.uk

This format is now deprecated for reasons given at the Shibboleth Wiki. When Identity Providers upgrade to recent versions of the Shibboleth software they will from then on provide a new format to services:

https://shib.example.ac.uk/shib!https://shib.service.ac.uk/shib!abcdefghijklmnopqrstuvwxyz

If the service was depending on the old format, they will not recognise the user and all the personalisation will be lost.

The Shibboleth Wiki advices service providers to update all their stored identifiers for users to the new format and then configure Shibboleth to convert the old-style to the new-style as they arrive. This means that as institutions upgrade their IdP software, the service receives the same identifier before and after, so users won't know anything has changed.

There is a slight problem: if users login via the WAYF, the IdP will give both formats and at the Service Provider side the old format will be converted and added to the new format, resulting in:

https://shib.example.ac.uk/shib!https://shib.service.ac.uk/shib!abcdefghijklmnopqrstuvwxyz;
https://shib.example.ac.uk/shib!https://shib.service.ac.uk/shib!abcdefghijklmnopqrstuvwxyz

I.e. the identifier is duplicated with the copies separated by a semi-colon (the line break and colouring is just to make this page easier to read). The Service now has to check for this duplication and use only one of the identifiers.

The code I wrote (in Java) to deal with this problem follows:

/**
 * Shibboleth SP may provide semi-colon delimited persistent-ids. We only want one of these.
 * @param input A header possibly containing multiple persistent-ids, to be parsed.
 * @return A single persistent-id, or null if they did not all match.
 */
public String splitPersistentId(String input) {
	if(input != null && input.contains(";")) {
		String[] splat = input.split(";");
    		
		// Check all the persistent-ids were the same, otherwise return null
		Set persistentIds = new HashSet(Arrays.asList(splat));
		if(persistentIds.size() != 1) {
			log.info("Given multiple non-matching persistent-ids: #0", input);
			return null;
		}
		
		// If they were all the same we can just return the first
		return splat[0];
	} else {
		return input;
	}
}

The code will take the possibly duplicated identifier and return just a single copy. The single copy can now be checked against a user database to personalise the service.

Some more information on this issue is available in the shibboleth-users mailing list archive.

Back to top