Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Contact our service desk and ask them to alter your entityID and scope on the system to the desired values as necessary.

    1. This will take effect immediately when changed so can affect access to resources if you have any people actively using OpenAthens accounts. You may wish to swap steps one and two.
  2. Connect your local source to OpenAthens. (see: Connections)

  3. If migrating from

    1. OpenAthens LA…
      1. Set the 'Unique user' attribute to be the same as the username field on your authentication store tab. This is usually sAMAccountName for Active Directory connections.
      2. Set the 'Salt value' to match the salt on the targetedID attribute(s) on the attributes tab.

    2. Shibboleth... look up the following in your attribute-resolver.xml file and:
      1. Set the 'Unique user' attribute to be the same as the sourceAttributeID. This is usually objectSid for Active Directory connections and this will add a step if you are going to be using ADFS as your local source. See: objectSid and ADFS
      2. Take everything between the quotes in the salt, including any brackets, and base64 encode it. Paste that base64 encoded value as the 'Salt value' in MD.

        Whilst this should work for any version of Shibboleth where you have used ComputedId as the targetedID generation method, and our service desk will always try to be helpful, they cannot support any third party software.

  4. Contact federations

    1. If you are only in the OpenAthens federation, this is automatic and you need do nothing more

    2. If you are in the UK Access Management federation or InCommon, you will need to contact that federation and either register your new entity or update your existing entity with your new endpoints depending on whether or not you are maintaining personalisation. This is usually just a case of the registered management liaison emailing them - see below.

    3. If you are keeping the same entityID, service providers will start to direct users to the new authentication point as they pick up the change from the metadata. This usually takes no more than a day.

  5. If you have registered a new entityID...

    1. You will need to contact your resource providers and give them your new details. You will usually have to arrange a changeover date.

    2. At the arranged time, your old IdP will no longer work for access to resources and your new one will.   

    3. You will have to update any WAYFless URLs you maintain with your new entityID (and for the older SAML1.1 type, your SSO address).

  6. If you have kept the same entityID...

    1. You will need to update any of the older SAML 1.1 type of WAYFless URL you maintain with your new SSO address. SAML 2 WAYFless URLs are unaffected.


You should just need to pass them your new entityID and scope as displayed on the organisation summary page and arrange a date.

Anything to watch out for?

Some service providers linked the user via a scoped version of targetedID. If your tests show that personalisation has been lost you can add a scoped version of targetedID to your release policy. Adding it on a per-resource basis is usually recommended, but it can be added to the global policy if necessary.