Outlook on the Upcoming Role Design in UCS and UCS@school

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.

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:

1. "Target object has the role 'Teacher'" and
2. "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!

Der Beitrag Outlook on the Upcoming Role Design in UCS and
UCS@school erschien zuerst auf Univention.

link