Introduction

Devolved constraints is an additional component of your institutional identify management strategy - it is an optional step, but highly recommended for those institutions able to implement it. Within Talis Aspire, it provides the method by which customers can take increased ownership of the roles and permissions of their users, removing the need to send invites.

This video is aimed at Talis Aspire customers who are considering devolved constraints and wish to find out more, as well as for those customers who have made the decision to adopt this approach and want to learn how to implement this solution.

The video is divided into three parts:

- Part One: How roles and permissions work in Aspire, the existing invite process, and some of the challenges this can present. [Starts 00:00]

- Part Two: Introduces the devolved constraints concept, constraints URLs and anticipated benefits of implementing devolved constraints. [Starts 05:30]

- Part Three: Provides more detail on implementing devolved constraints at your institution and explains the next steps for customers wishing to make this happen. [Starts 09:40]

Please note that, for those who prefer the written word, some of the content from Parts One and Two of the video is also included in the following article.

The problem

Over time, your Aspire implementation will be used by many tens of thousands of students and thousands of academics. Students generally will not have privileged roles in the system (such as list-creator), but most of those academics will. In addition, the courses those academics teach may change semester on semester, as new courses are added and custodianship of existing ones are passed to others. Finally, some academics may leave the institutions and new ones may join to take their place.

Although the invite system is a simple way to spread role membership to your user base when you’re first ramping up with Aspire, an administrator does need to action each and every invite.

Devolved constraints solves this problem by automatically ensuring that each and every user has the correct set of roles assigned to them each and every time they log into Aspire – from the very first time they log in.

How does it work?

To help explain devolved constraints, let’s refer to the concept diagram:

This shows how the constraint entity links together, for a given User, the Role (for example, List Publisher) and the Scope (where the user can play that role, for example an individual list). Using the invites process, an administrator sends an invite, a user accepts it, and a new constraint is created and stored within the Talis Aspire system.

Devolved constraints are not stored in Talis Aspire at all. Instead, they are passed to Aspire each and every time the user logs in, as part of the SAML envelope supplied by the Identity Provider. Just as with the verification of the user’s identity, the responsibility for supplying constraints is devolved to a third party system – the single source of truth for role membership at your institution.

What is my source of truth?

Talis Aspire receives the SAML envelope from the University’s Identity Provider – usually Shibboleth or a flavour of Athens. Just as with user names and passwords, Identity Providers are usually a gateway to enterprise systems within the University, which are the actual single source of truth for user’s identity. This is also true for constraints data – where you source your constraints information from will depend on which system you want to treat as the single source of truth for role membership. For some, this will be the same as the user identity, e.g. LDAP or Active Directory, but for others, role membership might come from the VLE or the registry.

To implement devolved constraints you must integrate this data source into your identity provider solution. The cost and complexity of this project will depend on your individual setup and local technical capability. Talis can help by putting you in contact with specialist partners who can undertake this work on your behalf if you are unable to complete the project yourself.

What does a Devolved Constraint actually look like?

The constraint is simply a special URL which tells Talis Aspire which role and scope you wish to constrain. It takes the form:

http://youraspireurl/constraints?role=ROLECODE&scope=MODULECODE

The scope scope parameter is optional – if you don’t supply it, Aspire will assume you want to allow the user to perform the role at “tenancy level”.

Using the role membership information contained in your third party system, you build one or more of these special URLs into the eduPersonEntitlement attribute in the SAML envelope that is sent back to Talis Aspire at login. As the set of devolved constraints is rebuilt each time the user logs in, the constraints Talis Aspire applies to the user will always mirror those at the single source of truth.

To make debugging easier, you can also place these special URLs into a web browser – Talis Aspire will return some XML to the browser describing the constraint you are requesting. Try this constraint from our test system, which describes a constraint for the list publisher role at tenancy level (i.e. the user can edit and publish any list):

http://lists.broadminsteruniversity.org/constraints?role=listpub

This returns the XML:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:constraint="http://purl.org/vocab/resourcelist/constraint#">
  <rdf:Description rdf:about="http://lists.broadminsteruniversity.org/constraints/E9BE0636-E546-3...">
    <rdf:type rdf:resource="http://purl.org/vocab/resourcelist/constraint#Constraint"/>
    <constraint:constrains rdf:resource="http://lists-sandbox.broadminsteruniversity.org/roles/list-publisher"/>
    <constraint:appliesTo rdf:resource="http://lists.broadminsteruniversity.org/"/>
  </rdf:Description>
</rdf:RDF>

The next example narrows the scope of the constraint to only allow the user to perform the list publisher role on lists attached to the module ABF203:

http://lists.broadminsteruniversity.org/constraints?role=listpub&scope=abf203

The XML for this one is a bit longer, so I won’t include it here (click the link to see it). Note that this time, four constraints are returned. Because ABF203 has 4 lists attached to it, Aspire returns a constraint per list.

What about pre-existing constraints created by the invite system?

If, to date, you’ve been using the invite facility within Talis Aspire, you can upgrade to devolved constraints and your users will retain the privileges previously granted to them by the invite system, alongside any new ones supplied via the devolved constraints integration.

How much does it cost to use Devolved Constraints?

Use of the devolved constraints feature is included with your Talis Aspire subscription – there is no extra cost to start using it.

However, to avoid any doubt, Talis Education can not provide support and guidance on you local authentication and identity management strategy or implementation. This remains the responsibility of the institution, and we can only advise in respect to specific integration with Talis Aspire (e.g. what requirements the institution must meet when providing entitlements via SAML from your IdP to our SP).

If your IT team is not capable of performing the local integration work to support the supply of the special URLs from your single source of truth (as described above) you may need external consulting assistance. To help you scope a project, we can put you in contact with both customers who have completed projects on their own, and specialist partners whose expertise is identify management who could undertake the work on your behalf.

Additionally, if you do not host your own identity provider locally there may be other charges involved for changing its configuration – talk to your hosting provider.

Summary

Devolved constraints extend the integration with your enterprise access management solution by allowing you to synchronise role membership with Talis Aspire. The maintenance overhead associated with manual invites during wide-scale rollouts can be eliminated, and users benefit from always having an up to date set of privileges from their very first login.