Bug 47880 - Limit visible modules in UMC
Limit visible modules in UMC
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC (Generic)
UCS 4.3
Other Linux
: P5 normal (vote)
: UCS 4.3-2-errata
Assigned To: Ole Schwiegert
Johannes Keiser
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-28 11:18 CEST by Frank Greif
Modified: 2019-06-25 13:10 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
Patch to 'univention/management/console/protocol/session.py' that filters visible modules in UMC. (1.42 KB, text/plain)
2018-09-28 11:18 CEST, Frank Greif
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Greif 2018-09-28 11:18:33 CEST
Created attachment 9684 [details]
Patch to 'univention/management/console/protocol/session.py' that filters visible modules in UMC.

I'm implementing the feature 'Delegated administration' for an UCS customer. I have implemented a separate UMC module that provides a filtered view of objects to be managed, and reduced forms according to the current admin's roles.

To make a transparent rights mapping onto UMC operations, I have to allow my admins to use a limited set of UDM functionality. Whenever I allow at least one UDM operation (for instance, udm/syntax/choices) the frontend presents all UDM modules to the current admin, even if it's clear that these modules cannot (and should not!) be used.

I have implemented a patch that will:

* honor an 'UMC Property' named 'modules': if it's present then only the modules mentioned there will be displayed
* does not change anything if the given property is not set.

Automatic maintenance of the attribute is already in place. It is part of the project to calculate the 'allowed modules' depending on roles assignments and managedBy relations.
Comment 1 Ole Schwiegert univentionstaff 2018-10-30 11:37:01 CET
The proposed feature makes sense indeed and should be implemented in some form. After discussion in our team though, we would prefer to implement this feature via Policies and a blacklist instead of a whitelist. We thought that the case is more that you want to forbid certain modules the user would normally see instead of creating a whitelist.

On branch oschwieg/4.3-2/47880 is my proposed implementation.

The UMC Policy is extended by the property 'module_blacklist' which is a string multivalue and expects strings in the form of:

'module' (blocks the entire module)
'module:flavor' (blocks the flavor of module)

The user object has a new internal property (not visible in UMC or UDM cli) 'module_blacklist' which is a dictionary calculated from the UMC Policies of the user itself and its groups when the user is opened in umd-python.
{
module_a: [*], # entire module is blacklisted
module_b: [flavor_a, flavor_b] # specified flavors are blacklisted
}

I did not implement the consumption of this new value in the session.py yet since I want to use the new UDM API from https://forge.univention.org/bugzilla/show_bug.cgi?id=47316 .

Are there any arguments against this proposed solution?
If the usage of UDM in the session.py proves to be too slow, I will resort to use direct LDAP queries. Though I hope that will not be necessary.
Comment 2 Frank Greif 2018-10-30 14:02:26 CET
Generally, I can change the logic of my 'permission adjuster' script such that it does not set the list of allowed modules but rather subtracts it from the list of available modules and sets them as a blacklist.

Currently, the script is a listener that watches the properties of objects that make up the 'permission concept', and then crawls through all objects that would be influenced.

If the list is a blacklist it would mean that the script additionally has to be invoked whenever the list of available modules changes, for instance when the admin installs a new package that provides an UMC module. I'd be grateful to get some assistance on how to 'listen to any changes to the list of available modules'. This is the only hurdle I see.
Comment 3 Ole Schwiegert univentionstaff 2018-11-08 10:54:38 CET
With the addition of this blacklist the determination of visible UMC modules works like that:

The list of visible UMC modules is determined by the set of UMCP operations the user is allowed to execute. This is determined by the UMC Policies of the user and its groups.

So the blacklist (which is at that moment also saved in the UMC policies) only removes modules from this already filtered set of UMC modules.

If I understand correctly your users have custom UMC policies already where you set the allowed operations. Your problem now is that you want to remove modules visible because of some specific allowed operations in your users policies.

Given that my previous assumptions are correct your users are not affected by newly installed UMC modules. Since they do not have the operation sets in their UMC policies they are not shown anyway.
Comment 4 Frank Greif 2018-11-08 12:01:38 CET
Seems I could not clearly explain the problems that my patch wants to solve:

(1) My module frontend needs the permission to call udm/syntax/choices, just to fill some comboboxes. If I make a simple policy that only allows this one entry then UMC shows all UDM modules even if I did not allow any single UDM flavor. So my patch wants to hide any UDM things that I did not really allow. -> Your idea (to place a blacklist into the policy, so one can forbid these modules) can solve this problem. But I don't strictly depend on this part of the solution because I could implement [my_module]/syntax/choices and proxy the requests to the desired syntax classes.

(2) I have one UMC module with (currently) six flavors. Depending on the 'permission concept' any of these flavors can effectively be allowed or forbidden at any time for the current delegated admin user. Using the current policy-based concept, I would have to prepare 2^6 policies with all combinations of visible/invisible flavors. And let's add a seventh flavor later... THIS is the real problem. Currently I have one policy that allows the module (all flavors altogether), and I would wish to let session.py show only those allowed, without using policies. Therefore the idea of a UMC Preference of the user, just like the flag that stores the grid view flag of the user module, or the preference of showing confirmations. -> THIS is the problem your solution attempt does not really address, especially because it's based on policies. My current workaround is to show all flavors (just like UMC works currently) and if the user opens a flavor without any current privileges then the module says 'there's nothing to do' and only presents a 'Close' button. If ever, I'd like to present a solution to my customer that does not show useless modules in this sense.

So, long answer short: if you implement it this way then the real problem remains.
Comment 5 Ole Schwiegert univentionstaff 2018-11-21 10:26:07 CET
Okay, I think we solved (2) here.

We did not like the original patch that much since we doubt it scales well in other environments where there are possibly dozens of users that potentially need filtering of UMC modules. Thus we tried to come up with a concept that can be applied to groups and improves UCS for a broader audience.

The proposed solution with the extension of the UMC Policy does not solve the problem either as you pointed out.

During the conception of other ideas though we figured out that you can actually solve problem (2) with the tools, that are already available to you in UCS right now.

Let me explain: The visibility of UMC modules is determined by which UMC commands the user is allowed to execute. So much we know already. These commands are grouped in operation sets which again are grouped in UMC policies which can be applied to either groups or users.

Therefore a user can see all modules that have commands he can execute determined by the UMC policies of himself and his groups and the operations sets they include.
The detail we are looking for now is, that in OperationSets you can define an optional flavor for the commands. That means this operation set is only valid if the flavor fits as well. This is actually how our operation sets for the different UDM flavors work. You can try it out by creating a Policy that allows for example only the udm-groups operation set.

Apply this policy to a test user and you will see that he can only see the groups/group udm module.

With that in mind we can implement your scenario as follows:

You have a new UMC module with six flavors. This UMC module brings a set of commands.
Now you create an OperationSet for each flavor containing all commands this flavor needs. Next for each OperationSet you create a new UMC Policy only containing this one OperationSet.
The next step is to create also a group for each flavor that has the corresponding UMC policy applied.

Instead of setting some UMC preference at a user now, you can just alter the users group membership for your six flavors and create any combination of activated UMC modules. All you need is 3 LDAP objects (OperationSet+Policy+Group) per module, or module flavor in your case.

Sadly (1) cannot be solved with this functionality. I was hoping that even if the command comes from another module, the flavor restriction would work in your custom Operation Sets. Sadly there is a nick with this. It is correct so far that even if the command is allowed for you, you would have no visible UDM modules in the UMC, but since the management console would not be able to find any module providing udm/syntax/choices with one of the flavors of your custom modules, it would not be able to start a udm module and process the command. Therefore you get a Forbidden from the UMC server when you want to execute the syntax command. If you can, as you said proxy the command through your own module you would have a solution for your use case at hand that works with the product as it is of now.

We will still look into that problem anyway, though I thought you might find this useful.
Comment 6 Ole Schwiegert univentionstaff 2018-11-21 16:25:53 CET
Package: univention-management-console-module-udm
Version: 8.0.5-26A~4.3.0.201811211621
Branch: ucs_4.3-0
Scope: errata4.3-2

I added requiredCommand sections to the flavors in the udm.xml. This requires a user to have ALL specified commands allowed to be able to see the UMC module flavor.

To be tested:
Does not effect normal users
A user can open a module flavor, search the list and open a single element without any errors if he only is allowed the minimal set of umc commands
Edit,Delete and Save are not included in the minimal set of commands

@Frank Greif: This change and my previous comment should enable you to realize your project with the specified requirements. If I overlooked any problem please leave a comment.
Comment 7 Johannes Keiser univentionstaff 2018-12-04 12:17:39 CET
Can you add missing requiredCommands for users/self in ./management/univention-management-console-module-udm/umc/udm.xml and for saml/serviceprovider in ./saml/univention-saml/umc/saml-serviceprovider.xml
Comment 8 Ole Schwiegert univentionstaff 2018-12-04 12:40:09 CET
Package: univention-saml
Version: 5.0.4-28A~4.3.0.201812041233
Branch: ucs_4.3-0
Scope: errata4.3-2


Package: univention-management-console-module-udm
Version: 8.0.5-28A~4.3.0.201812041235
Branch: ucs_4.3-0
Scope: errata4.3-2
Comment 9 Ole Schwiegert univentionstaff 2018-12-05 10:10:22 CET
Package: univention-management-console-module-udm
Version: 8.0.5-29A~4.3.0.201812051007
Branch: ucs_4.3-0
Scope: errata4.3-2

Package: univention-saml
Version: 5.0.4-29A~4.3.0.201812051009
Branch: ucs_4.3-0
Scope: errata4.3-2


We decided in a discussion to take out the detail view of an object from the minimal command set and restrict it to the overview page
Comment 10 Frank Greif 2018-12-05 10:49:27 CET
Exactly. This is where I came from: the detail view contains widgets (ComboBox) that issue their queries without flavor, and therefore you cannot make an operation set that strictly is tied to the flavor. Just for the record: I have worked around by arranging all ComboBoxes to get a custom UMCPCommand that adds the flavor. So I already can make an operation set *with flavor* which will include the choices calls.
Comment 11 Johannes Keiser univentionstaff 2018-12-05 11:03:14 CET
OK: requiredCommands on UDM flavors to open the module
OK: setup as described in Comment #5
OK: YAML
-> verified