How to maintain user identifiers when you move to a local connection
When you move existing users from OpenAthens accounts to using a local connector, the identifier that they present to a resource is changed. In most cases this does not make any difference to their experience in the resource, but in some cases it can cause your users to lose saved settings. The two factors that can make a difference are:
- One or more resources that you access link the user's targetedID to any kind of personalisation (e.g. saved searches, alerts), and
- You have users who make use of the linked services
You can maintain the end-users' original identifier by passing an additional attribute for these users as follows.
Prerequisites
- Access to the OpenAthens admin interface
- A local connection set up and ready.
- Access to your local data source to add additional data
Process
Download data from OpenAthens
- Go to advanced search and craft a search to return all relevant accounts across your domain - e.g. active accounts that are not expired across you and all sub-organisations.
- From the results, select the checkboxes for the relevant accounts (the select all option may be what you need, and you can also select a range using the shift key).
- Click the actions button that has appeared and use the download option. Depending on how many accounts you are dealing with, this may take a few seconds or several minutes. If you have a very large number of accounts (say 70,000 or more) you may not be able to download them all in one file.
- Once ready there will be a success box with a link to the file page. If you miss the select box, you can access the download file via the big downloads button on the homepage.
- Download the file to your computer - it is the data under
persistentUID
that you will need to add to your local accounts in your system.
Add the identifiers to the users in your local system
- Using your skill and judgement, match up the downloaded
persistentUID
data with the relevant users in your systems and add it to your directory. - Ensure that the attribute holding this data will be passed to us when the user signs in
- LDAP - should just work
- SIRSI - you will need to re-use one of the standard attributes such as
patronInfo.alternativeID
. - ADFS, CAS, SAML - ensure the attribute is included in the ones you release to us
- API - the attribute and value only need to be in the payload for the relevant users
- LDAP - should just work
Update the connector in the OpenAthens admin interface
These assume your local connector is already set up. The process is the same for every type of connector.
- Go to your connection (Management > Connections > Connector) and select the attributes tab
- Add a mapping
- The source attribute should be whichever attribute in your system contains the PUID values. The name is case sensitive.
- The target name must be
AthensMDLegacyPUID
- The display name can be whatever you like - perhaps 'Legacy PUID'
- Leave the releasable option cleared
- The source attribute should be whichever attribute in your system contains the PUID values. The name is case sensitive.
- Click on the done and then save changes buttons
The next time a user with a PUID mapping signs in via the connector they will present the same targetedID to a resource that their OpenAthens account did.
Anything to watch out for?
If there was a period between enabling the local connector and adding this step to maintain targetedIDs, any users who were active will have sent different targetedIDs during that period.