Since our last blog article on the future role model, we have made significant progress in transforming the UCS role and rights model. The custom role design, currently under development, is taking shape. In this article, we would like to focus on introducing two promising new components: One of them allows you to evaluate the permissions of a role, while the other is a web module that allows you to create your own roles. Let’s see what else awaits us until the end of the year.
Table of Contents
The Hand that Watches Over Everything – the ‘Guardian’
The central cornerstone of the new role model is a technical component that will be consulted by all modules in the future to determine user permissions. This component, named the Guardian, incorporates the Open Policy Agent, whose functionality we introduced in the article “Stubbornness does not suit us: Univention breaks the model of roles for UCS and UCS@school” in March, along with some features. In the following, I will briefly outline additional tasks the Guardian fulfills.
If an action is intended to occur within a module or application, the Guardian is asked to perform an evaluation based on the permissions that the user has for the specific module or application. It is not the components responsibility to enforce a policy within the module itself but rather to provide a simple ‘allowed’ or ‘not allowed’ response to the module.
However, more complex queries can also be processed, such as a request for a listing of all permissions that a user has for a particular module or application. That allows the user to design the interface of the module/application accordingly, displaying only the actions and attributes that the user is authorized to work with.
Furthermore, the Guardian offers interfaces for creating and modifying roles. That forms the foundation for a web interface of a role module, enabling administrators to create and conveniently manage their own roles through the web interface. We will delve into more detail about how such a module will look.
A Dedicated Module for the Design of Roles
As part of the work on the Guardian, a web module is developing, specifically addressing the design of roles, making an essential feature of the Guardian available to you.
Role module mockup
In the interface, you can manage all aspects of a role. From creating a role and defining its capabilities to specifying the context and namespace within which roles are allowed to operate. The context is crucial when a user is only authorized to manage other users within their sub-organization, department, or school. In the case of UCS@school, the context is equivalent to the school.
You can use the namespace for a more organized arrangement of roles. In the simplest scenario, you create a separate namespace for your individual roles, allowing you to distinguish them from the standard UCS roles. If you manage multiple departments or schools or have numerous apps you use simultaneously, you will likely need to maintain the ‘Administrator’ role more than once. Here, namespaces can help maintain an overview. For example, by creating separate namespaces for each app (Nextcloud, OX, etc.) or each school type (high school, vocational school, etc.).
But how are permissions assigned now? On the detail page of a role, you can define the abilities of this role. An ability consists of two parts: 1. permission and 2. conditions for when this permission takes effect. In this context, a role can have multiple capabilities. Let me explain this with an example: You create a role “Clerk” that operates in the context of the school “BeautifulSchool.”
This role is allowed to reset the passwords of all teachers if they also belong to “BeautifulSchool.”
To implement this, you create a new ability for the “Clerk” role with the following conditions:
- “Target object has the role ‘Teacher'”and
- “Target object is at the same school as me.”
and then define the associated permission: “reset password”.
The following mockup illustrates this example:
The mockup shows how the abilities of a role could be defined in the frontend of UCS@school.
Abilities that you can assign in the role module are supplied by the respective modules and applications. Therefore, the UCS modules must adapt so that their capabilities become known to the Guardian. Only then will they also be available in the role module. The scope will be limited for the initial release, and we will expand it in the following months.
First Possible Usage Scenarios
We planned the first release of the Guardian and the associated role module for the end of the year. It will be an alpha variant that will continue to evolve over the next year. Therefore, we recommend installing these components only in your own test systems for the time being to design the first scenarios. I will explain a few possible scenarios here using examples.
For the first launch of the role module, we have decided to make the actions and capabilities of the new school user module available, which we will also deliver at the end of the year. Thus, our UCS@school customers will be the first to benefit from the developments.
One scenario you could implement with the new module is to create roles that can modify school users but not create or delete them. Another is to limit capabilities to specific contexts, e. g. that a role ‘District Admin’ may create, delete, or modify school users at the three schools from their district. Or that a role “School Admin” may only create, delete, and modify school users at its own school.
Less obvious, but all the more practical, is the following scenario: you can give better oversight to the various players in the school operation. For example, you can give “school admins” who would get too much information about individual users in the current user module and too little in the school user module a more tailored view. You can do that by defining in the role module which attributes a user can read by the ‘school admins’ and which can be modified. A person with this role can then view and edit only the attributes you specify in the new school user module, while other attributes will be displayed as ‘secret’.
Exemplary representation in the new school user module when a role does not have the privilege to access first and last names.
A Few Final Words
We are already looking forward to releasing the new features of the roles and permissions model by the end of the year and are very excited to see the use cases you will be implementing first. Feel free to share your ideas for use cases with us and other UCS and UCS@school users as comments.
If you would like to actively contribute to the further development of role design and be among the first to share your feedback with us, please don’t hesitate to contact me personally. After the modules are released, we will involve you closely in the development process and look forward to your valuable contributions. Together, we create an even more effective and user-friendly solution. Thank you very much for your support!
