Accessing ScienceDirect

Initiating a Shibboleth Authentication Request from a library home page or other customer portal

Introduction

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 ScienceDirect, this is implemented via the “Institution Login” link on the ScienceDirect homepage, then via ScienceDirect’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 ScienceDirect through your federation directly from your library page or website, without them having to go to ScienceDirect 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 ScienceDirect and access materials under federated authentication 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 ScienceDirect as the target Service Provider and include the specific ScienceDirect 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 ScienceDirect, or, if they are already logged in to your authentication service, they will be transparently re-directed to ScienceDirect and be given access.

Authentication Request URLs for ScienceDirect have this generic syntax:
[IDP_HANDLE_SERVICE_URL]?target=[SD_TARGET_URL]&shire=https%3A%2F%2Fsdauth.sciencedirect.com%2FSHIRE%2FSAML%2FPOST&providerId=https%3A%2F%2Fsdauth.sciencedirect.com%2F

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

Please note that [SD_TARGET_URL], [SD_ASSERTION_CONSUMER_SERVICE_URL] and [SD_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 [SD_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 [SD_ASSERTION_CONSUMER_SERVICE_URL] and [SD_SP_PROVIDER_ID] are (in URL encoded format) “https%3A%2F%2Fsdauth.sciencedirect.com%2FSHIRE%2FSAML%2FPOST” and “https%3A%2F%2Fsdauth.sciencedirect.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 main page of the journal Cell on ScienceDirect (http://www.sciencedirect.com/science/journal/00928674) then the session initiation URL for this is:

https://shib.some-institute.edu/idp?target=https%3A%2F%2Fwww.sciencedire... shire=https%3A%2F%2Fsdauth.sciencedirect.com%2FSHIRE%2FSAML%2FPOST&providerId=https%3A%2F%2Fsdauth.sciencedirect.com%2F

In principle, all ScienceDirect URLs can be used as target URLs, however it is safest to use ScienceDirect’s published set of persistent “Short Cut” URLs to link to specific pages in the site as these are guaranteed not to change (again - bear in mind to use the https:// prefix). For more information on persistent ScienceDirect URLs, go here: Setting Up Short Cut Links.

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.