Detail rights from combined roles

Hi Peter,

I understand that this behavior would make things a lot easier to set up in dossier-oriented roles, where the available case data is gradually expanded when roles are added.

When we do this, we should consider extending this to not just details but also to include lookups, table-tasks, table-reports and menu items, navigational items which aren’t entities themselves.

There are a few challenges that make this a bit more difficult, such as performance of model loading, auditability and validations on detail rights.

But the most challenging aspect is on a functional level. The result of a change such as this would grant many details for tables which were only granted to allow for look-up translations.

For instance, the system has trace fields which resolve to an employee name. Most roles grant the employee table for look-up purposes, to allow the employee's name to be shown. This means that the employee detail will always be shown, for all entities. There is no way to turn this off using roles anymore.

Likewise, when extended to other navigational objects, the menu item for employees would also become available.

We could look into a new form of rights on navigational objects, (lookups, details, table-tasks, table-reports and menu items) which flags them as granted-if-available. In your example, you’d will need to flag the detail from calculation to product in the calculation role as granted-if-available. This preserves the fine-grained control without the need for extra roles.

Hierarchy or dependencies in roles could also resolve this to an extent. You’d still need a third, lightweight role which shows the calculations per product. But this role would be configured so it can only be granted when the user has the product-related role and the calculation-related role. An application administrator could be assisted with smart suggestions based on these dependencies when they set up roles for a user group in in IAM.

Hi Anne, 

Thanks for your reply.

For instance, the system has trace fields which resolve to an employee name. Most roles grant the employee table for look-up purposes, to allow the employee's name to be shown. This means that the employee detail will always be shown, for all entities. There is no way to turn this off using roles anymore.

I think you misunderstood me here, so just to be clear: I don’t think it should work that granting rights for a table would automatically grant the rights for the detail of that table to be shown. I always meant for it to work that the rights for the detail should still be explicitly granted to a role, with the only difference that the detail does not need to be available in the same role.

So what you describe as granted-if-available is exactly what I’m looking for (as long as the availability may come from a different role). Though I fail to understand why a new form would give less challenges than how the current authorisation would work if something as granted in a role without the available checkbox would always be evaluated as granted-if-available. But if a new form is needed, then sure.

I am not a big fan of hierarchy or dependencies of roles because this could get rather complex fast while the power of good IAM management is setting clear/simple roles in my opinion.

Allowing the ‘granted’ setting to have this effect when ‘available’ is false could also be a solution, yes.

However, ‘granted’ is present in many more role rights scenarios than just navigational model objects such as details. If we’d use the ‘granted’ setting, consistency dictates that it will also apply to other grantable objects, such as columns, task parameters, process flows. For example: you can grant a column with a role on a table that is not granted and when the table is granted via another role the column also becomes available.

I’m quite worried what this would do with performance, as many more calculations to determine availability would have to be done at runtime based on a set of roles.

Furthermore, the complexity of setting up roles and the auditability would be even more difficult if this would also affect columns and such. Navigational structures don't really affect the information available to the user, but column authorization does.

A version of the platform that would support this would have to turn off all ‘granted’ settings for items which are not available, as they would suddenly start having effect. This can be done once during the upgrade, but this cannot be done for dynamic-model generated role rights, they may suddenly start working differently.

Having a separate, extra field when a detail is granted but not available to indicate the detail may also be granted if it becomes available via another role allows us to limit this to use cases which are more manageable, such as details.

If we’d use the ‘granted’ setting, consistency dictates that it will also apply to other grantable objects

Agreed
 

I’m quite worried what this would do with performance, as many more calculations to determine availability would have to be done at runtime based on a set of roles.

You maybe got a point here, although there probably should be some kind of solution possible to avoid everything at runtime. For example a system flow in IAM that makes these calculations in the background whenever something is changed that could affect this. 
 

Furthermore, the complexity of setting up roles and the auditability would be even more difficult if this would also affect columns and such. Navigational structures don't really affect the information available to the user, but column authorization does.

I disagree, I would even argue that it would become more simple and clear. Of course this is somewhat dependent of how you design each role but it gives us the possibility to make roles more precise. It could also help with dynamic code that could grant rights to a subject based on if the role has select_granted = 1 on a table without having to worry about lookup/detail tables that you don’t want to be included.

Currently one role about a specific subject (= coherent set of tables / tasks / etc.) also needs authorization on a lot of different subject tables just because there is a lookup/detail that needs it. This means that you easily lose sight of what that role is actually about. This also makes it harder for a developer to determine if a new column should be added to a role or not.

A version of the platform that would support this would have to turn off all ‘granted’ settings for items which are not available, as they would suddenly start having effect. This can be done once during the upgrade, but this cannot be done for dynamic-model generated role rights, they may suddenly start working differently.

While I am not against such a conversion on upgrade, still let me ask you: why would anyone set something as granted but not available in the current situation? I can’t see any reason to do that consciously.

For dynamic models you could easily make a query to select the ‘generated_by_control_proc_id’ that have set granted while there is no availability. So you could notify developers to check/modify that script with this change.

Having a separate, extra field when a detail is granted but not available to indicate the detail may also be granted if it becomes available via another role allows us to limit this to use cases which are more manageable, such as details.

I would be Ok with this, I guess it could always be set automatic with dynamic code anyway.

In principle, the idea that having multiple roles gives you more than simply the sum of the individual parts is something that chafes against the principle of least privilege.

While I can see how this approach would make for easier development, it would be quite the challenge to implement, both on an auditability level as well as performance-wise.

I’m not certain whether the effort and benefits outweigh simply adding a third role which allows (in your case) the calculations to be viewed in context of the products.

But we’ll keep the idea open, I’m curious to hear other developers’ input on this!