Devolved Authentication

This article outlines the methods that we will use to authenticate your users for access to Talis Products.


Talis supports devolved authentication for all our products. This is where we ask one of your university authentication systems whether the person attempting to log into our software should be allowed to continue. We are deferring the decision to your university’s identity management systems.

This has the benefit that:

  • We never see or store usernames or passwords for users.
  • Your identity management system can choose what information is released to us about your users.
  • Users who need additional permissions in Talis software can be granted these by your identity management system. This is through a mechanism that we call Devolved Constraints (read the article)


To login to any Talis software, you will need to have an identity management system which supports SAML-2. We typically use a SAML-2 Single Sign On (SSO) service using the HTTP-Redirect binding provided by your Identity Provider (IDP).

For example:

  • Shibboleth
  • Open Athens LA
  • Open Athens MD
  • Ping Federate
  • ADFS (Active Directory Federation Services)
  • Microsoft Azure Active Directory
  • CAS (Apereo)

If you have another system which you would like to use then do let us know.

We do support Open Athens DA - but there are some limitations inherent in the Open Athens DA service which means that you will not be able to take advantage of Devolved Constraints

Required Attribute Release

You will also be required to release a specific attribute to us. This has a friendly name of eduPersonTargettedID, but the actual name we expect to see is urn:oid: The following XML can be seen in our Service Provider metadata. You can read more about the official description of eduPersonTargettedID.


The value in this attribute is often a hash of the following pieces of information:

  • The entity id of your Identity Provider
  • The entity id of our Service Provider
  • The username of the user logging in.
  • A random salt known only to the institution.

Sometimes this is combined with the ‘target’ for example :, though this is not necessary.

A full example might be:

This value is used to uniquely identify the user to our systems. This value should not change. If it does change we would treat the user as being a new user. If there is any work that you are carrying out that might mean this value would change, then you should raise this with the support team as soon as possible. There may be work that you will need to schedule in order to ensure that users do not loose access to their profiles, bookmarks, lists etc.

Optional Attribute Release

We recommend that you also release user attributes that make use of Talis Aspire personalisation features easy and seamless.


You may also choose to release another attribute to us which is known as the eduPersonEntitlement. Please see this article on Devolved Constraints and Entitlements for more details on why you might choose to do this.

Metadata Exchange

In most cases, if your institution’s Identity Provider (IDP) is registered in a federation, then we can use that as a mechanism to exchange metadata.

We do not use federations to actually provide the login path for users, instead choosing to communicate directly with your IDP after looking up its details in the federation.

If you do need to see our metadata, you can view/download this from here:

User login expectations for Talis Products

Talis Aspire Reading Lists (TARL)

For Talis Aspire Reading Lists login is only required to make changes or interact in the system. For example a student may choose to capture reading intentions or an academic may choose to edit a list.

Students do not need to login to TARL to view their reading lists (unless the academic has chosen to make the list ‘private’).

Talis Aspire Digitised Content (TADC)

Students will need to login to be able to view, print or download digitisations. This is to satisfy the terms of the appropriate copyright licences in effect at your institution.

Back office staff will need to be logged in and verified as users who should have access to the workflow management tools in TADC.


If you need to know what attributes have been sent to TARL for debugging purposes, then you can do the following:

  • log into Talis as the user for which you want to check their attributes.
  • go to the following location: ( for Canadian institutions)
  • you will see a ‘dump’ of the values that we are seeing.
Have more questions? Submit a request


Please sign in to leave a comment.