Migrating authentication systems

Background

Aspire authentication is based on the use of a Persistent ID for every Aspire user. Some customers may want to make a breaking change to their authentication system, which would mean users' persistent IDs will change. This maybe for a number of reasons:

  • Major shift from Athens to Shibboleth
  • Change of server names
  • Change of certificates
  • Move from bi-lateral agreement to UK Federation 

How to Migrate

In order to begin a migration, customers must raise a support ticket providing us with:

  1. The Entity ID of the new IDP as defined by the federation (this should look like a URL)
  2. A test account for the new IDP so it can be tested by support.
Support will then perform a number of checks before implementing the new IDP authentication configuration.

Parallel migration from "legacy" to "new"

We can run an Aspire tenancy with a "legacy" IDP authentication configuration in parallel with a "new" IDP authentication configuration. This is the preferred method and works for ALL users regardless of their profile within Aspire, or whether they have an email address in the system. Administrative users who have the IDP Migration permission can access the IDP Migration console from the Admin section of Aspire providing visibility on the progression of the migration which may be useful where there are deadlines to meet.

In this method, once we have set up the new configuration, when a user logs into Aspire for the first time following setup of the new IDP, they will be asked to log in again, against the legacy IDP and will be presented with the below message:

IDPMethod1-LoginAgain.jpg

Once the user has logged in against the legacy IDP, this completes their migration and the system will match Persistent ID with the  data associated with their legacy Persistent ID  e.g. bookmarks, lists, profile information etc. 

Users with the System Admin role can access the IDP Migration console from the Admin section of Aspire. This enables these users to view the progress of the migration, including how many users have migrated, how many are yet to migrate as well as the Legacy and current IDP configuration information.

IDPMethod1-adminConsole.jpg

Summary

The Dual-Run of a legacy and new IDP is an activity which must have an end point and it is likely that  you have a deadline. It is important that you notify your users to ensure they log into Aspire during this time to ensure that the migration is completed. 

Finally, for customers using devolved constraints, you will need to test the devolved constraints also work against your new IDP before migrating your users.

Have more questions? Submit a request

9 Comments

  • Avatar
    Georgina Parsons

    Useful intro, thanks. Our initial questions:

    In Method 1, it says that sysadmins have a "progress report" available. It then goes on to explain a migration console. Are these different, is there a detailed progress report in addition to the console? We would absolutely need to be able to see a list of users who haven't yet migrated, so we can chase people up to ensure that academics don't lose everything just because they've not been able to log in during a set timeframe.

    To clarify the detailed needs, it couldn't just be like the All User Profiles report (will that work during migration, by the way?). We would need to see whether the user had any bookmarks/lists/roles as well as just their name/email, and their last login date, so we know which users we want to worry about.

    Also, can I assume the Summary refers to both methods even though it's a subheading of Method 2? It does sound like it; can we get more detail on how the 'laggard' users should be handled? If they didn't log in during the dual-run process, what would they see the next time they logged in to Aspire - I guess it would still let them in but they wouldn't see any profile info. Would they see a message giving them information about this and what to do? Would we also get an alert (presumably to the sysadmin) telling us that user is now awake and we can get in touch and migrate them using an invite? We can't rely on them contacting us, they are equally likely to grumble and give up. Can we set this according to the type of user please (i.e. we'd only want to do this for academics not students - either identifiable by their Aspire role or, if they have no role yet, by the amount of bookmarks they have or their username, we could look at the criteria in detail in due course)?

    (PS The noun is "login" and the verb is "log in" - can you update the text on the button users have to press to migrate their profile, please? In fact, is that whole pop-up customisable?)

  • Avatar
    Keji

    Hi Georgina,

    My apologies for mixing up terminology there. There is no report, but there is the admin console which tells you how far the migration has progressed i.e. how many users have migrated and how many are outstanding. I have updated the article to reflect this.  I've also included a new screenshot in the Summary section which displays what the 'laggard' users would see if they logged into Aspire.

    No emails are sent to system admins as a result of the laggard users log into Aspire and the text on the pop-up is not customisable but if you have a suggestion which can be applied generically, we're happy to consider it.

     

  • Avatar
    Georgina Parsons

    Thanks for the quick clarification. We're worried about the lack of knowledge on who's migrated and who hasn't; if the system knows how many users have migrated and how many haven't, can't it also tell us who they are? 

    However, the new detail in the summary is really useful - many thanks for that update. We now see that Method 1 simply becomes Method 2 and before the old authentication route is switched off, we have to go into admin and send an email to all unmigrated users first (again, we would really want to know who they are, as we find that people are better at following instructions with librarians on hand; furthermore, if the email comes from noreply@talisaspire.com then it's probably going to be binned immediately anyway, as happens with our invites!).

  • Avatar
    Georgina Parsons

    Sorry, more questions! Can we customise the text used in the email in Method 2? Also, if you aren't able to provide lists of users by the time we need to migrate, can we have the ability to send these emails while running with Method 1 in order to keep nudging people? (Or would that cause any problems?) Thanks.

  • Avatar
    Kate Price

    Hello,

    I would like to make a comment about the progress of our migration from Googlemail accounts to OpenAthens LA 2.2. Technically it has been pretty smooth (just a couple more laggard accounts to migrate). However, it has been necessary to contact Support to get real information about who has and hasn't migrated their account. Our IPD migration console says that 35 users on the current version (OpenAthens) and 20 users are still on the old system (Googlemail). However, the real picture is that there are only 3 accounts left to migrate. Not sure where the number 20 comes from - it may be because some of the Googmail accounts are duplicates or generic. I would like to echo Georgina's comment that it would be much more helpful if the IDP migration console could list the unmigrated accounts, so that we can make a judgement on whether these are real or not, and can then give the all clear to complete the migration. Hopefully this would save Support having to deal with these queries for future migrations!

    All the best,

    Kate

     

  • Avatar
    Keji

    Hi Kate,

    Thanks for the feedback. We took Georgina's comments on board and we are expecting to release this week an Unmigrated Users report which will give you the details of your unmigrated users. You can see its progress on the 'In Progress' board.

  • Avatar
    Georgina Parsons

    Hello,

    I just wanted to check where things were regarding the corrections/improvements to the pop-ups etc. (As requested I emailed some suggestions and they were put on the stack.) In particular we need to be sure the message is about changing authentication on *Aspire* only so we don't get enquiries for other systems. Can the screenshots above maybe be updated with the new information shown/sent?

    Thanks,

    Georgina

  • Avatar
    Keji

    Hi Georgina,

    This was done as part of an unannounced release which had some technical fixes in it, back in August.

    • The button label was changed to "Log in again
    • The pop-up content was changed to say: "The University has recently changed the login procedure for its online reading lists. To ensure your profile, bookmarks, permissions, and other settings are not lost, please now log in once more. This will complete the process and no further action will be required."
  • Avatar
    Georgina Parsons

    Brilliant, thanks! Was the pop-up in the "Warning" box shown in the summary section also amended (re clarifying the authentication system and "Log out")?

    Thanks.

Please sign in to leave a comment.
Powered by Zendesk