Setting up SSO for Similarity or SimCheck

Shibboleth

Turnitin provides Single Sign-On (SSO) support through a standardized integration with Shibboleth SSO.

Getting set up

In order to use Turnitin’s Shibboleth SSO integration, you must raise a ticket with Turnitin support, and our team will help you through the setup process. Before you contact us, please read the rest of this guide to learn more about what information is required for the setup.

Federations

If you would like to configure Shibboleth SSO on your account, you must first become a member of a compatible federation.

Below is a list of federations or projects involving Shibboleth or SAML technology provided by the Shibboleth project with which we are partnered. Each federation typically serves a specific community:

• AAF Federation (Australia)
• AAI@EduHr (Croatia)
• DFN-AAI (Germany)
• EduGain (via InCommon)
• Feide Federation
• GakuNin (Japan)
• Haka Federation (Finland)
• IDEM (Italy)
• InCommon
• Porto Federation (Portugal)
• SURFConext Federation (Netherlands)
• SWAMID (Sweden)
• SWITCH (Switzerland/Europe)
• UK federation

To set up Shibboleth, we will need your Shibboleth Entity ID. This is typically a URL or URN format string, like `https://my-production-shib.thing.edu` or `urn:mace:incommon:thing.edu`.

Contacting Turnitin

If you are a member of a compatible federation and have your Shibboleth Entity ID, then you can contact Turnitin to request Shibboleth SSO be set up for your account.

To contact Turnitin, visit our help center to raise a ticket, and our team will help you through the setup process.

Users roles

When signing in to Turnitin using Shibboleth SSO, users will automatically be designated the ‘User’ role.

Required user attributes

To ensure accurate reporting, meaningful similarity comparisons, and reliable user-based searching, your Identity Provider (IdP) must send specific user attributes as part of the SSO authentication process.

While Similarity / SimCheck can operate without these attributes, their absence results in incomplete user data. This can affect statistics, prevent similarity scores from being compared by author, and limit the effectiveness of the paper lookup tool. In practice, missing attributes are a common cause of unexpected behavior after SSO implementation, so we strongly recommend confirming that your IdP is sending the required attributes listed below. The sub-items show alternative attribute names that our service recognizes, listed in order of preference.

• Given Name
  • givenName
  • urn:mace:dir:attribute-def:givenName
  • urn:oid:2.5.4.42
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
• Surname
  • sn
  • urn:mace:dir:attribute-def:sn
  • urn:oid:2.5.4.4
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
• Email
  • mail
  • urn:mace:dir:attribute-def:mail
  • urn:oid:0.9.2342.19200300.100.1.3
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Additional settings

Optional group members

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

Optional URL to send users upon logout

If provided, will redirect Similarity/SimCheck to this URL upon logout. Typically, this would be a URL that logs out the user from your IdP.