You need to have identity software that supports SAML 2.0 and has access to your users' directory, and you need to be a member of a federation in your country.

When your IdP metadata is available in your federation, our systems will automatically consume it within 24 hours. When you're ready, you can contact your Elsevier representative or Elsevier support to request access activation.

Your national federation builds and maintains a shared trust infrastructure that enables interoperability, automation, standards compliance, and community policies to keep users and organizations secure.

It aggregates member IdP and SP metadata, refreshing it daily for all members. This reduces your operational burden by eliminating the need to share metadata manually, coordinate timelines, or negotiate protocols. When you update metadata or certificates, changes are made once and automatically propagated to all partner SPs.

Similarly, when updating a signing certificate, we do it in one place instead of coordinating via email with thousands of customers.

We support the SAML 2.0 protocol, so if you configure your identity software to meet our requirements, your users can access our services regardless of the software used; including, but not limited to, those mentioned in the question.

Our entityID=https://sdauth.sciencedirect.com/ with display name ‘Elsevier’.

The metadata is available through your federation.

Our aim is to have all Elsevier products and services available through this SP but that’s not the case yet.

The list contains, but is not limited to, ScienceDirect, Scopus, SciVal, EngineeringVillage, Embase, PharmaPendium, ClinicalKey, Mendeley, JournalFinder, and so on.

The IdP must release one of the following pseudonymous attributes, in order of preference:

1. SAML PairwiseID - OASIS document
2. SAML SubjectID - same document as above

We still support these attributes for backward compatibility, but if you’re setting up a new IdP, please consider pairwiseID or subjectID, instead:

3. eduPersonTargetedID - deprecated - ePTID
4. Persistent NameID - deprecated - must be opaque, non-reassignable, it is case sensitive.

Optionally, if you release the email attribute, the email field will be populated when a user creates an Elsevier account:

• mail

We don’t store personal data without user’s consents.

When a user creates an Elsevier account, we link the pseudonymous attribute against their account so that we can show them their content on their return. This is not preventing user from keeping their account when they change organization and lose institutional entitlements.

If you release email, first name, last name, they are used to populate the registration form but a user is able to modify that data.

Personalization is optional in many of our products (ScienceDirect, Scopus, EngineeringVillage,..), it allows users to save or create content, lists, alerts and similar. Without an available pseudonymous attribute, a user may end up in complicated authentication flows.

In some products (such as in Mendeley, SciVal, ClinicalKey Student, etc.) the personalization is mandatory and access without a pseudonymous attribute doesn’t work.

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 can 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.

Yes.

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.

Access via your IdP will be activated once it is linked to your organization’s Elsevier account by Elsevier support. To initiate this, please contact your Elsevier representative or support and provide:

• Your organization name
• The entityID of your IdP
• The ePE or ePSA values, if applicable
• The name of your federation

Once access is activated, your users can sign in via your IdP by selecting your organization within the product. You may also set up WAYFless URLs for direct access.

More information about this process is available here.

We only support SP initiated session.

Our SP manages SAML-based authentication for multiple Elsevier products, each with their own domain.

This method doesn’t work:

[the_IdP_SSO_URL]?PartnerSpId=https://sdauth.sciencedirect.com/

because our SP doesn't know which product a user wants to visit.

To build a link directly to a desired product, please construct a WAYFless URL.