Elsevier is standardizing its SP metadata in eduGAIN
Last updated on October 15, 2025
Elsevier implemented support for SAML-based authentication nearly two decades ago, becoming one of the first service providers to join the UK Federation. Since then, we’ve enabled this type of access for over 2,000 customers across more than 50 countries; supporting scalable, secure, and user-friendly access to Elsevier products and services.
Before the introduction of eduGAIN, negotiations and configurations were federation-specific and they varied. Over time they have increasingly aligned with the standards, improving scalability and interoperability.
We are now further evolving the modern authentication infrastructure that will deliver:
- A single, authoritative SP metadata set in eduGAIN
- Enhanced user experience
- Improved access control for libraries
- Strengthened security and SIRTFY compliance
Our aim is to create an environment where a user only needs to login to once, in order to be able to access all the services that their home organization subscribes to and any other they may be interested in, with one click.
In addition, the configuration and instructions for customer IdPs and our support should be simple.
With a large number of products and services, existing customers and users, that’s a lot of moving parts that are being aligned in phases.
We are updating our SP metadata to achieve consistency across all federations and end up with one authoritative set of metadata in eduGAIN.
Specifically, we are:
- Adding required attribute elements to the metadata, where they were previously optional or missing
- Communicating these changes with IdP operators directly, ahead of updates
The Elsevier SP is a proxy that manages SAML authentication across many products. This allows users to authenticate once, and to access all their entitlements whether via their institution or personal account.
- For most products (ScienceDirect, Scopus, EngineeringVillage…) a personal account is optional
- For others (Mendeley, SciVal, ClinicalKey Student…) it is required
Users can still access content anonymously on products like ScienceDirect, even if their IdP releases a pseudonymous attribute.
Most IdPs already release [the required attributes], and their users experience minimal access issues or we get minimal abuse.
However, some IdPs hold back these attributes unless they are explicitly requested in metadata, which is what we are addressing now.
Pseudonymous Attribute:
When a user authenticates via an IdP and creates an account with us, we link a pseudonymous attribute to their account to recognize returning users. When no registration occurs, we discard the attribute.
The only exception is for security; when we detect suspicious crawling behavior, we are able to link it to the pseudonymous attribute and block individual access. We then report the potentially compromized credential to the IdP. (SIRTFI compliance)
Entitlement Attribute:
This allows us to grant access only to entitled users, and the IdP decides which users or user groups are entitled. However, both the IdP and Elsevier must be aligned on the value of this attribute for it to take effect.
Missing pseudonymous attribute:
Users may experience login loops or difficulty creating a personal account, leading to confusion from having two different credentials and various ways of using them.
We now display such a message to the user, which also offers them the alternative access option, when applicable.
Missing entitlement attribute:
When a value is configured on our side, users without that value will not gain access, although they can still visit many services as guest users.
If the IdP prefers to use scoped affiliation for this purpose, that will work in the same way.
Users with access or personalization problems contact our customer support or their library, who gets in touch with us in their name.
Everyone struggles to diagnose problems because the root cause is hidden inside an encrypted SAML assertion, which is not retained and even if it was, humans aren’t able to decrypt, by design.
To help with this, we’ve introduced a new screen that informs users of potential authentication issues in advance and, when possible, offers them alternative access paths.

Users with on a happy path are not being shown any of these screens, they get access directly.
Did we answer your question?
Related answers
Recently viewed answers
Functionality disabled due to your cookie preferences