Knowledge Base/Official Talis Aspire Support/New Customer Implementations

Devolved Authentication Guidelines for Talis Aspire

Ian Corns
posted this on January 06, 2011 13:59

Overview

This document provides both business users and technical staff background context to how Talis Aspire Campus Edition works with devolved authentication solutions.

Context

Devolved authentication allows a browser user to access protected online resources based on information asserted by their home organisation, whilst allowing providers of online resources to control access to their services. Talis Aspire Campus Edition supports SAML 2.0 compliant devolved authentication, via single sign-on.

There are two main components to devolved authentication:

  • Identity-Provider (IdP): Controlled, provisioned and operated by the institution or institution's IT partner. The identity provider authenticates users on behalf of 3rd party services (such as Talis Aspire Campus Edition)
  • Service-Provider (SP): Controlled, provisioned and operated by 3rd party vendors (such as Talis Education). Decides which resources within the service to secure and when to ask the IdP to identify users.

At the highest level, there are two primary user scenarios.

  • An un-authorised user within Talis Aspire Campus Edition attempts to access a protected resource (e.g. page or service). The SP will determine the IdP for that user and issue an authentication request. The user is re-directed to an endpoint at the IdP typically called a "Single Sign-On Service". The IdP prepares an appropriate response to the SP with consideration of the user’s credentials, initialises a session for that user and redirects the users browser to the protected resource/page.
  • Within the current browser session, the user has already been authenticated by another service provider and attempts to access Talis Aspire Campus Edition. Here, the Talis Aspire SP will still initiate a call to the IdP. However, the IdP will detect the users existing sign-in session and authorise the user to the SP without the user being required to login again.

Talis Aspire Campus Edition can be configured to operate:

1. Via a National Federation (recommended)

The institution and Talis Education exchange both licences and configuration information with an authorised third party.

Talis Aspire interoperates with (a) the UK Federation and (b) the Australian Access Federation [AAF]

2. Via a bilateral agreement

The institution and Talis Education directly exchange configurations to setup their IdP or SP, as well as directly exchange metadata during the authentication negotiation. Talis Aspire Campus Edition supports Shibboleth 2.0 or OpenAthens LA/DA (note that for Athens DA you will need individual user accounts - see FAQ below). If you are using any other service, please contact your Talis representative for more information.

The following diagram illustrates these differences:

Bilateral_vs_UK_Federation.key.png 

Configuration

Via the UK Federation

If the institution is a member of the UK Federation, there is no configuration requirement. We would ask that:

This information can be provided in the tenancy set-up questionnaire.

Via a Bilateral Agreement

The process for configuring your IdP with Talis Aspire Campus Edition is relatively simple, and is the same as what would be conducted when configuring any SP.

This process involves two steps.

  • Firstly, the exchange of metadata between the two parties, with Talis Education providing its SP metadata to the institution and the institution providing its IdP metadata back to Talis Education.
  • Secondly, each party will configure the provided metadata, with reference to the DA method being used. Once these two steps are complete, the authentication service should be operational and ready for testing

Talis Education require that the customer sets-up a test account on their IdP, to allow testing and troubleshooting of the integration. Once the integration has been completed, this test account should be maintained by the institution to allow Talis Education to perform future tests and support.

From experience, we have learnt that the configuration exercise is one of iterative steps towards completion of the integration. To expedite this, we strongly recommend a single nominated point of contact (with telephone/email details) be provided by the customer for the individual responsible for the devolved authentication configuration.

 

Frequently Asked Questions

What attributes must be provided by the IdP as part of the authentication negotiation?
The only mandatory attribute is the persistentID (eduPersonTargetedID), without which Talis Aspire Campus Edition cannot be used. The identifier for the attribute is urn:oid:1.3.6.1.4.1.5923.1.1.1.10. It is important to note that a consistent persistentID must be returned by the IdP to enable Talis Aspire Campus Edition to recognise returning users.

In addition, customers with Athens DA should note that Talis Aspire Campus Edition requires that individual users have their own accounts and as such an Athens DA set-up with group accounts (e.g. same shared account for all students) is insufficient.

In a demo of Talis Aspire Campus Edition, it was explained that the students “My List” page can be auto-populated with lists for modules they are currently studying. How?
As part of the authentication negotiation, the customers IdP can provide the module codes, for the modules being studied by the user, under the eduPersonEntitlement. This is an optional element to configuring the service. This is reliant on the customer having both a reliable source of truth with the information, and the institution being able to integrate this service with their IdP so eduPersonEntitlement can be provided.

To do this, the eduPersonEntitlement should be populated by a single string of module codes which are space-delimited, for example "ABF203 FDTA102 TRE637 GRE638" (quotes not required). On receipt of this string, Talis Aspire will provide links to these lists from the students My Lists area.

What resources and pages within Talis Aspire Campus Edition require authentication?
If effect, any page that requires a login or action that requires either identity or a permission to be performed. This includes bookmarking resources, editing/maintaining list, viewing acquisitions information, students adding notes, viewing My Bookmarks or My Lists, etc.

We are a member of the UK Federation. Are Talis Education?
Yes. Our membership profile is here: http://www.ukfederation.org.uk/content/Services/2011-05-03-talis.

Customers currently authenticating via bi-lateral agreements cannot at this time convert to authenticating via the federation without loosing user data. We intend to provide a migration path, with users retaining all data, in due course.

We are considering changing our DA method. What impact will this have?
If you are considering moving from one version to another or from one method to another (e.g. OpenAthens to Shibboleth), the only requirement that Talis Aspire Campus Edition has is that the persistentIDs that have been previously used for identifying users in the previous system/version are preserved in the new system. It is the customers responsibility to ensure this is the case. Should you face any difficulties in preserving ID’s between systems, Talis Education can offer a bespoke conversion (chargeable project) where we will amend all persistentIDs within Talis Aspire Campus Edition. It will be, however, still the customers responsibility to provide the mapping file for old ID’s to new.

Do you support Shibboleth 1.3?

Shibboleth 1.3 was moved to end-of-live as of June 30th, 2010 (http://shibboleth.internet2.edu/shib-which-version.html). For this reason, Talis Aspire Campus Edition no longer support this, or previous, versions.

What are the minimum requirements for single sign-on authentication?

Please see http://support.talisaspire.com/entries/20282557-what-are-the-minimu....

 

References

 

Last Updated: 19th July 2011

END