Roles and Permissions in Talis Aspire: Part Two

November 3rd, 2010 - 2 comments - Posted by in General News.

This post is the second in a three part series about roles and permissions in Talis Aspire.

In my first post I introduced the key terminology: Roles, Permissions, Scopes and Constraints, as well as introducing the invite system which allowed users to take on roles.

In this post I’d like to focus on a feature called Devolved Constraints, an extension of the Single Sign On (SSO) or Devolved Authentication mechanism already used to authenticate enterprise users to Talis Aspire. Devolved constraints supplement or can even replace the invite process, allowing the University’s enterprise access management system to send role membership information, as well as identity information, each and every time a user signs into Talis Aspire.

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 described in post one is a simple way to spread role membership to your userbase 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 go back to the concept diagram introduced in the first post.

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-3047-EFFE-233358328D13">
    <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.

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 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 syncronise 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.

In my third and final post in this series I will be detailing some of the improvements to user management and authentication we will be making in the new year. In the meantime, if there are any questions about devolved constrains and how it is implemented, please get in touch with me at chris.clarke@talis.com or via the comments box below.

Discussion and Debate

  1. Richard Cross on November 29, 2010

    Nottingham Trent University is successfully using Devolved Permissions (through Shibboleth) for Talis Aspire. This means that we have been able to retire our Invite based authorisation workflow entirely, and are able to confidently rely on an automated authorisation mapping for all academics using Aspire.

    Our ‘source of truth’ is the roles and permissions data held in the Virtual Learning Environment which links academics to their modules. After mapping the available roles within the VLE to the roles (currently) available within Aspire, we completed the necessary technical work to: translate those VLE role names to Aspire role name formats; build the correctly formatted SAML envelope containing the attribute data; and configure our Shibboleth IdP to release that data to the Aspire SP.

    This means that with no manual intervention, academics logging into Aspire are automatically associated with (and have editing rights for) all of the matching modules and lists they are responsible for maintaining. There is no requirement for academics to contact the library in advance, or make arrangements to be ‘assigned’ to their resource lists, because this is automatically taken care of by the devolved permissions process.

  2. Glenn Wearen on December 16, 2010

    Nice work, more of this sort of thing!

Leave your thoughts...

Written by...

Categories

Recent Archives