Athens/Shibboleth

To log in with Athens or another institution login, go to: log in on Scopus. Then click the link Athens / Other Institution login.

Athens

Scopus has supported the Athens Access Management system since 2002. Athens provides users with single sign-on access to numerous web-based services, and is widely deployed throughout the United Kingdom amongst the Higher Education and Further Education communities and many NHS (National Health Service) trusts.

Athens allows end users to access Scopus with the same credentials as other content sources, enhancing ease of use. An additional benefit is that Athens allows end users to access their organization\\'s subscribed Scopus content from anywhere and at anytime, not tying them to one physical location.

For institutes, Athens is a method of centralizing resource access management, reducing overheads and increasing scalability.

For more information on Athens , go to http://www.athens.ac.uk/.

Shibboleth

Scopus is an avid supporter of the Shibboleth family of architectures, policy structures, and technologies that allow organizations to exchange information about their users in a highly customizable, secure and privacy-preserving manner.

Increasingly deployed in the academic community, Shibboleth allows end users to access multiple information resources with one set of credentials and on a single sign-on basis, while providing extensive protection of identity and personal details. Furthermore, Shibboleth allows end users to access their organization\\'s licensed content from outside the organizations physical network.

For institutes that deploy Shibboleth, the main benefit is centralized management of resource access, and integration of access to online, remote content resources with locally deployed authentication systems.

Organizations - both content providers and their customers - that have adopted Shibboleth work together in so-called "federations". A federation defines what set of rules to use for the deployment of Shibboleth for its members, thereby allowing the customization of the Shibboleth concept to meet the needs of that particular group of organizations.

Since 2004 Elsevier is a member of the InCommon federation in the United States, and in August 2008, expanded its service to be able to support other federation memberships as well. Scopus is increasingly joining federations in other parts of the world, offering Shibboleth to an ever-growing number of our customers.

For more information on Shibboleth, visit our FAQ, or go to  http://shibboleth.internet2.edu/.

To talk to Scopus about federation memberships, contact us at nlinfo@scopus.com.

How to construct direct Shibboleth authentication links

Typically, a Shibboleth session is initiated by a Service Provider (SP) issuing a Shibboleth Authentication Request to the user’s Identity Provider, either directly or via the federation’s WAYF. On Scopus, this is implemented via the “Institution Login” link on the Scopus homepage, then via Scopus’s local WAYF implementation where the user can select a federation and IdP institution, before being redirected to their chosen IdP’s login functionality. However, it is also possible to let users log in to Scopus through your federation directly from your library page or website, without them having to go to Scopus first, by building appropriate Authentication Request URLs yourself. This removes a few steps in the login process, and makes it far more intuitive for users to get to Scopus using Shibboleth.

Implementation

To implement direct Shibboleth login functionality from your website, you need to build Shibboleth Authentication Request URLs to your Shibbolised institutional login service which identify Scopus as the target Service Provider and include the specific Scopus target URL you would like the user to land on after authentication. These links will force any user clicking on them to first enter their institute's credentials before going into Scopus, or, if they are already logged in to your authentication service, they will be transparently re-directed to Scopus and be given access.

Authentication Request URLs for Scopus have this generic syntax:

[IDP_HANDLE_SERVICE_URL]?target=[SC_TARGET_URL]&shire=[SC_ASSERTION_CONSUMER_SERVICE_URL]&providerId=https%3a%2f%2fscauth.scopus.com%2f

In this URL, [IDP_HANDLE_SERVICE_URL] is the URL of your institute's Shibboleth Handle Service, [SC_TARGET_URL] is the URL of the Scopus page you want to direct the user to, [SC_ASSERTION_CONSUMER_SERVICE_URL] is Scopus’s Shibboleth assertion consumer service URL as currently published in your federation’s metadata and [SC_SP_PROVIDER_ID] is Scopus’s provider ID also published in your federation’s metadata.

Please note that [SC_TARGET_URL], [SC_ASSERTION_CONSUMER_SERVICE_URL] and [SC_SP_PROVIDER_ID] need to be encoded using URL-Safe encoding (see this page: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm for more information about how to do that). Also, the [SC_TARGET_URL] needs to have a https:// prefix, and not a http:// prefix - this is because Shibboleth-authenticated sessions use secured http communication.

The current values of [SC_ASSERTION_CONSUMER_SERVICE_URL] and [SC_SP_PROVIDER_ID] are (in URL encoded format) “https%3A%2F%2Fscauth.scopus.com%2FSHIRE%2FSAML%2FPOST” and “https%3A%2F%2Fscauth.scopus.com%2F”, respectively, however as these could change from time to time and you should ideally generate your URLs dynamically using the latest values of these elements as published in your federation’s metadata.

Example:

If your Shibboleth handle service URL is https://shib.some-institute.edu/idp, and you want to point your users to the Journal Analyzer on Scopus (http://www.scopus.com/scopus/source/eval.url), then the session initiation URL for this is:

https://shib.some-institute.edu/idp?target=https%3A%2F%2Fwww.scopus.com%... https%3A%2F%2Fscauth.scopus.com%2FSHIRE%2FSAML%2FPOST &providerId=https%3a%2f%2fscauth.scopus.com%2f

In principle, all Scopus URLs can be used as target URLs - as long as you remember to use a https:// prefix.

Note: this functionality has been built and tested using a standard Shibboleth 1.2/1.3 implementation. It might work differently, or not at all, for hybrid solutions such as the Athens-to-Shibboleth gateway, for other SAML-based (non-Shibboleth) authentication schemes, and future Shibboleth versions.

For general information on Shibboleth, see http://shibboleth.internet2.edu/.