How can we help?

We’re moving our guides on 9th March 2019. See a preview of their new home at
Home > iThenticate > iThenticate Shibboleth Integration

iThenticate Shibboleth Integration

iThenticate provides Single Sign-On (SSO) support as a Service Provider (SP). This document describes the process to create a Shibboleth integration with iThenticate and the required and optional attributes provided by your institution’s Identity Provider (IdP).


In order to use iThenticate’s Shibboleth integration, you must first contact your iThenticate Sales Representative to initiate a discussion on the requirements of a Shibboleth integration. Please familiarize yourself with this guide beforehand so you are able to provide all the requisite information (attributes and additional settings).


This document is intended for technical administrators of your IdP. Please note that depending on your requirements, there may be additional charges involved with integrating with iThenticate.


Your IdP must be configured in order to send the attributes listed below, and you must have an iThenticate account provisioned to work with your IdP.


The current iThenticate Shibboleth configuration requires the following information and released attributes:

  • Your IdP identifier (Shib-Identity-Provider)
    This will typically be a URL.


  • The federation that your institution belongs to
    We currently exchange metadata with many federations and this will be the easiest and fastest way to integrate with iThenticate.

    In some cases we will use an institution's metadata directly. If integrating directly with your IdP, we require your IdP metadata URL and the public key if the metadata is signed. The Turnitin/iThenticate metadata can be found at


  • The attribute that you use to uniquely identify users on your system
    This should never change. For example, ePPN or targeted-id.


  • Attributes for first name, last name, and email address
    These are for user interface display purpose only and are never released to any third-party. You should provide the following:


  • givenName
    This is the user’s first name; if a name is not provided, this will default to “iThenticate”.
  • sn
    This is the user’s last name; if a name is not provided, this will default to “User”.
  • mail  
    This is an email address where the user may receive emails. If a valid email is not provided, an inactive (for example, email address will be created as a placeholder.


Additional settings

You will need to provide answers to the following questions:

  • Allow Shibboleth-created users to share folders (and therefore documents) with other users?
  • Allow users to select a ‘reporting group’ when uploading documents?  
    Reporting groups are created up by account administrators and users can be assigned their default reporting group.  This option allows users to select or change the reporting group associated with their submissions.

iThenticate has two user roles: standard users and administrators.  Administrators have the ability to manage users. iThenticate does not support setting or changing this role via Shibboleth.


All users must agree to the iThenticate EULA the first time they log into iThenticate. iThenticate users, created via a Shibboleth integration, cannot log in via the iThenticate website login page.


iThenticate will update the user’s name or email address from the data provided by the IdP if changed.


The iThenticate support team will provide the login URL to the account administrator once the Shibboleth integration is completed.

Optional group membership

We can use isMemberOf (urn:oid: to control access to the iThenticate account associated with your IdP.  By default, anyone that can authenticate on the IdP can access the iThenticate account. Using isMemberOf is recommended so that the institution can control access to the iThenticate account for specific groups.

Optional URL to send users upon logout

If provided will redirect iThenticate to this URL upon logout. Typically this would be a URL that logs out the user from your Idp.

Mapping users by email

Some institutions may already have an iThenticate account and would like to use Shibboleth as their SSO solution.


The first time the Shibboleth user logs into iThenticate using SSO, their account will be linked to the existing iThenticate account. To enable this request, your Shibboleth integration must be configured to map user accounts by email.  Your IdP must then provide the “mail” attribute, prompting iThenticate to look for an existing user in your account with a matching email address.  The email address must be unique within the iThenticate system for your account.


SECURITY NOTE: Use caution when enabling this feature. If you allow your users to add or modify their own email address in your IdP or user directory service, this could allow access to other user data in iThenticate.

SSO workflow

An iThenticate account will be automatically provisioned the first time a new principal (user) logs into iThenticate. Subsequent SSO logins will update the user’s attributes (first name, last name, email) as provided.



Direct your users to the iThenticate SP. You will be provided with the login URL once your account is configured.


The user will be redirected to your IdP if they are not already authenticated.


The user will provide the IdP with credentials and then redirected back to iThenticate.


Review and agree to the iThenticate End User License Agreement.


Begin using iThenticate.



Last modified


This page has no custom tags.


(not set)