Background
Lean Library Workspace is a set of reference manager features that allow your users to collect citations for resources and then collaborate on projects with other users, and enabling tracking of citations and their styling in documents. This article outlines some important considerations about the choice of authentication and how it might affect your users ability to continue to use Lean Library Workspace when if subscription comes to and.
Key concepts
Shared projects
Users can create shared projects containing references, and shared annotations made on the full text article resources. This allows a group of researchers to highlight interesting parts of articles to their collaborators.
User licences
Users can have access to a freemium or premium version of Lean Library Workspace independently of the institutional subscription. User's are assigned a licence to allow them to access the premium features, such as increased limits on shared projects. The licence can either be paid for by the Institution or the individual. Licence allocation is managed as part of the authentication of the user to the institution.
Access to shared projects
Long term access to shared projects can be affected by the choice of authentication method. The rest of this article outlines the options and how they relate to user management and shared projects.
Choosing an authentication method
The institution will need to decide which of the licence allocation models best suit their expectations and the expectations of their users.
Authentication methods
Individual user accounts
A user can create a Lean Library Workspace account and use the freemium features in Workspace without having to request permission from the institution.
The account is authenticated using a username and password, or using an individual's Google or Facebook accounts. The profile is created by the user when they sign up independently of any institutional systems.
IP Access
You will give us a list of IP addresses that are considered to be 'on campus' for the purposes of identifying a user logging in from that location. This is similar to a list of IP addresses that you may give to a publisher to allow access to full text services via a proxy.
Users will create 'individual' Lean Library Workspace accounts where they choose the email address and password to use to identify themselves. This could be a personal email address. This could also be an existing user account where the user has worked at a previous institution but that licence has lapsed when they left.
When the user logs in on your campus, they will be detected as logging in under you institutional account, and the premium features will be activated.
The user has to come back to campus to login at least once every 120 days, or their access to premium features will expire.
If a user leaves the institution, their access to premium features will expire when they have not logged in from the campus after 120 days and they will loose access to premium features. They will retain access to shared projects and their resources. They will retain 'ownership' of shared projects.
Your IP address ranges should be for the external IP addresses seen by us as a result of Network Address Translation (NAT), and not IP addresses in ranges reserved for internal network use.
Setup IP Access
To setup IP Access, please raise a support ticket with a list of the IP address ranges that should be considered on campus
Single Sign On
Your users will authenticate using your single sign on service. Lean Library Workspace will ask your SSO "Should we let this user in?" and your SSO will decide.
A user's profile will be identified using the email address associated with the Single Sign On account they used to login to Workspace, and a licence will be assigned to give users access to the premium features.
If a user leaves the institution, they will no longer have an SSO account, and so will no longer have access to their Workspace account nor the premium features. They will loose access to their resources and to shared projects.
The user is free to create their own individual accounts, and the user could be re-invited to share projects that they previously had access to if the user is still collaborating but under the auspices of a different institution. However they would not be able to regain the 'ownership' of a share project, nor would they be able to access resources previously collected in the SSO account.
Users would need to take action before they leave to create an individual user account and then share their current SSO account's projects and references with the new account.
Setup SSO Authentication
To Setup SSO Authentication please raise a support ticket and we will guide you through the process. We will need the name and contact email of the person who is responsible for configuring and testing Single Sign On at your institution. This is usually a member of your IT team.
Supported SSO services
We support he following Single Sign On services
- Any authentication software that supports the SAML protocol, including, but not limited to Microsoft Entra, Microsoft Azure, Microsoft ADFS, Ping Federate, Shibboleth.
- OpenAthens We can support this either through SAML or through a direct OpenAthens connection.