View by category
Which SAML attributes does Elsevier SP require?
Last updated on August 26, 2025
For a comprehensive IdP configuration FAQ please visit How do I set up federated access as a librarian or administrator?
Elsevier SP manages SAML-based authentication for a wide range of our products and services, each with distinct identity requirements:
- Some are accessible to anonymous users but offer enhanced features for optionally registered users (e.g., ScienceDirect, Scopus).
- Others require user personalization (e.g., SciVal, Mendeley).
- Various subscription models apply, including access:
- Through the library’s subscription (e.g., Embase, EngineeringVillage),
- Freely available (e.g., Mendeley),
- As a hybrid of free and subscription-based layers (e.g., ScienceDirect),
- By invitation or approval (e.g., ReviewerHub, Pure),
- And more.
To ensure a seamless user experience across our ecosystem and simplify IdP attribute release policies for operators, we have established a minimum set of requirements that address all these needs.
An IdP must release one type of pseudonymous attribute. We support four types, listed here in order of preference:
- pairwiseID (as defined in the OASIS specification)
- subjectID (from the same OASIS document)
If the IdP currently releases one of the following deprecated attributes, it may continue to do so temporarily:
- eduPersonTargetedID (deprecated; also known as ePTID)
- persistent NameID (deprecated; e.g., "12345abcde"; must be opaque, non-reassignable, and case-sensitive)
The pseudonymous attribute links institutional credentials to the user’s Elsevier account. Linking is optional unless the user accesses a product requiring mandatory personalization.
This attribute also enables us to detect and block unauthorized activity without affecting other institutional users and to report potentially compromised credentials to the IdP, ensuring compliance with SIRTFI standards.
Note: The attribute values do not need to be known to Elsevier in advance.
- Our IdP is freshly being configured for access to Elsevier
Then please release PairwiseID; it’s a modern and safe attribute.
- Our IdP is already configured for access to Elsevier but not releasing PairwiseID
Please release the PairwiseID attribute in addition to the attribute you are currently providing to us.
This allows Elsevier to recognize returning users by their existing attribute while silently adding the new attribute to their user accounts, preserving their personal settings. After about one to two months, you can discontinue releasing the old attribute.
If you switch directly from one attribute to another without overlap, returning users will not be recognized and will need to complete a manual linking process. While this is possible, it may cause confusion. For more information, see: How can I link my new to my old institutional/SSO credentials?
- Your SP metadata in eduGAIN and our local federation doesn’t match
We are working to align our metadata across all federations while ensuring uninterrupted access for existing users.
The Elsevier SP metadata published in eduGAIN takes precedence over any local configurations.
- Why does your SP in eduGAIN require 3 pseudonymous attributes
This is the only way for an SP to signal which pseudonymous attributes we support. We only need the IdP to release one of them.
The eduPersonEntitlement can be released as one of the two versions:
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" or
name="urn:mace:dir:attribute-def:eduPersonEntitlement"
The default value we look for is "urn:mace:dir:entitlement:common-lib-terms". A user without that attribute in their SAML assertion will not get access to your subscriptions.
If needed, the IdP can coordinate with Elsevier customer support to set up a different value.
If releasing an ePE is not possible, this can also be discussed, provided the IdP does not grant institutional credentials to non-entitled users such as alumni, affiliates, or library walk-ins. The value to be released must be communicated to Elsevier in advance.
If the IdP wants to distinguish between different user groups with ePSA, that can be done.
The eduPersonScopedAffiliation can be released as one of the two versions:
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"
A shared IdP must release ePSA so that we can tell between different organizations.
Please note that we evaluate the entire attribute value, and the relevant values must be shared with Elsevier support to be configured on our end; otherwise, they will be ignored.
Did we answer your question?
Related answers
Recently viewed answers
Functionality disabled due to your cookie preferences