Re: [Unity-idm-discuss] Some issues with inspector role

[Krzysztof B. <kb...@un...>]

Hi Sander,

W dniu 27.05.2019 o 14:58, Sander Apweiler pisze:
> Hi Krzysztof,
>
> within unity 2.4.2 we found some issues for users having the inspector
> role.
>
> 1. A user has inspector role in root group. Within the root group
> another entity is disabled. Instead of getting the user list, the
> inspector sees this error: "Problem retrieving group members:
> pl.edu.icm.unity.exceptions.IllegalIdentityValueException: The entity
> is disabled"

Yeah, that's a bug and it is still here with recent version, but shows 
up differently.

My take for this would be to deprecate the Inspector role, or better 
said - merge it with Privileged Inspector, which works correctly.

Do you have anything against? The difference is that Privileged 
Inspector can read just everything. It is also suggested workaround.

> 2. A user is regular user in root group and inspector in one subgroup
> (/a). The attribute CN got the attribute metadata "Value of this
> attribute in the root group is used as an entity's displayed name."
> This attribute is copied by attribute statements within the subgroup.
> The inspector only sees the list of entities without the name. If the
> inspector selects one of the entities, the inspector got the lists of
> available attributes. After selecting one of the attributes, the
> inspector can read the attributes.

Hmm, what is the problem here? Sounds all right: can read attributes in 
a group where it is an inspector, but not from root group where it is 
not an inspector.

> 3. A user is regular user in root group, inspector in first level
> subgroup (/a) and contents manager within second level subgroup (/a/b).
> The user tries to copy another user from /a into /a/b. The user got the
> following error: "Access denied. The operation getGroups requires
> 'read' capability". If the user get inspector role in root group too,
> it works.

Unfortunately this is also by design. In general roles in subgroups are 
of very limited usefulness: in order to perform many of the operations 
on subgroup level one needs some permissions on the global level.

Our approach to this is basically UpMan. It implements access to a 
subgroup with precisely controlled global impact (which always happen as 
side effect of authorized operation on a subgroup). If more flexibility 
on subgroup limited management is required we need to put more feature 
in UpMan, instead trying to figure out some generic authZ abstractions 
which are too hard to develop and understand. We tried hard with it for 
many years and always failed. And in UpMan its both well controlled and 
easy.

Best,
Krzysztof