Moodle Contexts are King

9 November 2021 by Catalyst

This is the 3rd post in our Moodle Security Mini Series. Within the Moodle Learning Management System’s (LMS) security model lies spaces known as Contexts. Contexts are specific areas within Moodle, where user roles can be assigned. Let's take a look at Contexts and explore how they work with roles to help keep your Moodle secure.

Mini Series Post 2 - Role based access control with Moodle

 

Where contexts fit in Moodle

Moodle contexts align with the principles of good security architecture, that dictate duties should be separated, as much as possible.

User roles are applied to contexts, where a context is a unit of your Moodle installation, be that a course, a course category, an activity module, a block, or the entire Moodle system itself. Note, contexts can also be users, so one role can be applied permissions over another using their context.

Context categories

Moodle has, by default, seven different contexts, each of which afford an assigned role a different scope of control. These seven contexts are as follows:

  • User - a Moodle user
  • System - the entire Moodle system (also known as Global Context)
  • Course category - a group of courses
  • Course -  a single course
  • Activity - a course activity and its associated resources
  • Block - a Moodle block
  • Front page - the front page of the Moodle system and all files accessible outside of courses

Hierarchical structure

Contexts are hierarchical and each is a self-contained area of the system to which the user has abilities to undertake specific tasks, designed as its scope.

The way you organise your role-based access control (RBAC) permissions and access model aligns in the same way the management structure of a business is organised, where you have divisions split across areas such as human resources, financial management, delivery service, etc. 

Within each division of your organisation, you will have teams carrying out specific aspects of that division’s overall objectives, such as a department within Human Resources dedicated to hiring new people. Someone working in the Resourcing Team will inherit the permissions and rights they need to do their job from the role they are assigned, and the contexts within the Resourcing Team. However, the manager of that division, may be assigned a higher-level context, as part of the broader Human Resources Team, giving them global rights over resourcing and privileges as a manager in Human Resources. 

To implement your hierarchical context structure in Moodle, role assignments should be made at the correct level. For instance, Teachers are usually assigned their context at the Course level, while a Forum Moderator would be assigned at the Activity level. Administrators are assigned the System context, which afford them significant powers across your Moodle system. 

How roles work with contexts

Any role can be applied to a context, so it’s up to the Moodle solutions team or architect to use their knowledge of your organisational hierarchy and skill levels and functions of your teams to create the right roles to map to your contexts. As an example, Moodle won’t prevent teachers from being assigned the system context, but we strongly advise against this kind of assignment as it makes troubleshooting very hard.

Since contexts have hierarchy, permissions naturally flow down from the higher level to those below (based on the structure shown in Figure 1). The permissions and rights assigned to higher level contexts are broader than those assigned at lower contexts. 

A five row table showing the different contexts and hierarchy within Moodle
Figure 1 - Context hierarchy in Moodle

The System context, also known as the root, sits at the top of the hierarchy. Any role assigned to the System context will also apply to all the contexts below it in the hierarchy. Course Category is the parent to the Course context, but if you have elected to use sub-categories, then they become the parent of the Course context.

Modules and Blocks are the lowest level in the context hierarchy and exist both within the Course branch and the Front Page branch. From a Moodle perspective, the Front Page is treated like that of a course, while the User context is standalone without child contexts.

The concept of inheritance is important in the Moodle security model, since rights and permissions set at one context level are passed down to lower levels to simplify administration. You can override this flow down process, changing assignments at lower levels, in case the flow down is not sufficient for how your security model should work. 

Multiple role assignments

You can assign multiple roles to users in Moodle, as certain users may wear different hat depending on the job they are doing. Some Teachers, for example, may also be Course Creators, while others are not. A Head of Department, for example, may be setting the teaching schedules and creating contexts for all the Teachers in that department to use. That same Head of Department may also teach her own classes, so she operates in two different role categories. Similarly, a College Facilitator might also have some operational duties in running Moodle, such as updating content on behalf of Teachers, but they may also be Administrators in Moodle as they enrol new users and assign them to classes.

 Importantly, Moodle allows you to assign multiple roles to a user at the same time, which can be as dynamic as you need it to be. For example, a Teaching Assistant might take over running the classes on behalf of a Teacher while he is on long service leave, but then when the Teacher returns, the role and context assignments are revoked and the levels of permissions will revert to how they were before.

Leverage the power of the Moodle security model

The Moodle security model is incredibly powerful, allowing you to map the Moodle administration hierarchy to your organisational needs using a combination of role and context assignments. It’s important that you to take time to manage the design accordingly, as inappropriate permissions or rights over your Moodle system can leave the business exposed to cyber threats and has the potential to cause both confidentiality and privacy breaches. 

Premium Moodle Partner services to support your LMS

red letter M with a red mortarboard hanging off the top left hand corner

The Catalyst Team has in-depth experience in designing the most complex, Enterprise Moodle solutions for organisations in the Higher Education sector.  We can provide expertise that helps to ensure your roles and contexts are working in your favour to protect your organisation’s most valuable assets. 


Contact the Catalyst Team Today

Moodle Premium Partner Logo