As support for OpenAthens LA is ending you will want to migrate to another solution. You have several options, but your easiest path is to migrate to hosted OpenAthens. and this guide covers how. The guide is tailored to users in the UK Access Management federation, but all federations will be similar.
If you are unclear or unsure, our service desk will be happy to help. They will also connect you to the right people if you are interested in arranging a consultancy which has options for on-site work and training.
Decisions to make first
The biggest decision is about your entityID. You can have a new entityID when you migrate or keep your existing one. Both have advantages:
Keep same entityID | Use a new entityID | |
---|---|---|
Advantages | Maintains the user IDs seen by publishers Publishers do not need to update your subscription settings No need to coordinate times with publishers | Completely fresh start Both can appear in the same federation at the same time |
Disadvantages | EntityIDs must be unique within a federation so both old and new can't be in the same federation at the same time | Users appear to publishers with a different ID (per-user settings can be lost) All publishers must update their subscription records with your new details at the same time |
Keeping the same entityID
The advantages are that you do not need to coordinate a change with all service providers, and it becomes possible to maintain the users' targetedIDs so that they do not lose personalisations such as saved searches or bookshelves.
The UK fed metadata is usually updated at 16:30 and after it changes to point your entityID at hosted OpenAthens there will be a period where the resources have not updated their cached copy of the federation metadata and will still to send users to OALA, so you will need to keep that running for a time to maintain access . How long will depend on your set of resources but most will pick up the change inside a day. Keeping an eye on the statistics reports in both OpenAthens and OALA will show you which, if any, resources are lagging and may need a reminder to update their copy of the metadata.
The following assumes you want to maintain the user IDs seen by publishers. If you don't, there are still advantages to keeping the same entityID but you can skip step 2.
Using a new entityID
Further configuration / equivalent functions
The items here are things you can do at any time during the migration and apply whatever you decide about entityIDs
Release policies
The essential difference is that in OpenAthens, release policies are only additive - i.e. you can't say 'if it's provider X do not release Y', they are all 'if it's provider X do release Y'.
The default policy releases targetedID, scopedAffiliation and entitlement. In most cases you will not need to add any additional policies, but if you do you search for the resource and tick the attributes that you want to release. You can change the NameID format on an SP by SP basis and even alias the attributes if the SP needs them called something else.
For details see:
Mapping attributes
There are two considerations here. If you will want to release the attribute to a publisher, or use it in reporting, then you will need to map it to an attribute you have created via the schema editor. If you merely want to display the data in the interface then you can just make up a name.
For details see:
'entitlement' values
The value pairs for these are baked into permission sets. Set it up there and assign to users on the permissions tab of your connection.
For details see:
Statisitcs
Stats are aggregated on a handful of default attributes and any others you specify via the schema editor.
Default stats aggregations:
- Permission set
- Resource
- Organisation
Anything else you want, such as user ID, will need to be mapped to an attribute that is marked as reportable.
For details see:
Additional service providers
If you want to connect to a SAML SP that isn't in a mutual federation - e.g. your VLE - you can create the connection via the resource catalogue.
Go to Resources > Catalogue > Custom tab > Add > SAML and upload the metadata. Once done you'll just need to set up the release policy.
For details see:
Anything else?
Because some publishers don't restrict access properly based on attributes there is an option to have us not send a response to a resource that isn't specified by permission sets assigned to the user. This is called restrictive mode and if you decide to use it you will need to ensure that all users get assigned an appropriate permission set and that those sets contain the relevant resources.
Do not turn it on until you are [fairly] sure you've allocated things correctly. The setting is at the bottom of the page under Preferences > Organisation.
For details see:
Retiring OALA
Once the migration is complete, all publishers are sending users to the correct authentication point, and working as you'd like you can turn off OALA. Before you do, you might like to take copies of some of the files for historical stats, sentiment or 'just in case':
From the OALA admin console you might download a copy of your configuration. See How to backup and restore administration console databases
From the runtime(s) you might zip up the folder /var/log/openathens
and store it somewhere. You might prefer to just export the stats database to CSV though. oala-categories.idx is probably the one you want:
>sqlite3 /var/log/openathens/oala-categories.idx sqlite> .headers on sqlite> .mode csv sqlite> .output data.csv sqlite> SELECT * FROM totals; sqlite> .quit
Transfer the file with your favourite SFTP client.