Roles & Authorities 1.5

[jbee]

Motivation

The current authority system has major issues that are systemic and require redesign to be solved.
The main issue being the logic used to determine if a user can grant roles to other users. The current logic makes "stale" authorities a big issue and also makes it important to know the superset of all authorities and their importance in the system which is difficult to compute or know with the current system. In addition it is unclear for users to why they can or cannot grant roles as the logic is way to sophisticated and can be analysed by looking at many objects and consider their interaction with each other.

The suggestion therefore is to change the granting logic in such a way that stale authorities are no hinder, the superset of all authorities is not that important, and so that granting becomes transparent.

Problems

The following problem list includes further issues that are not just related to granting of roles logic.

• no clear life-cycle for authorities
• no clear set of all authorities
• different groups of authorities are hard to consider ("hard-coded", schema-related, app-specific)
• much of the code assumes a fixed, static set of authorities (also apps) where the reality is that of both static and dynamic
• no notion of essential and non-essential authorities (can the system become unusable by removing certain authorities?)
• hard to consider the escalation and delegation of authorities (and considerations around when or how this breaks or creates loopholes)
• authority granting can get into "locked in" situations

Problems related to granting roles

• users can easily end up with "stale" authorities (e.g. from an uninstalled app) which in itself is not a problem but such stale authorities effectively block managing the affected user as the managing user doesn't have the stale authority but would be required to.
• user managing users need to be granted all the authorities that are meant grant to other users because of how the logic works
• adding or removing authorities to/from user roles can effectively break the workflow for user managing users
• for users it is nontransparent why they can or cannot grant roles as the logic is complicated and depends on lots of objects in the current system

Solutions

Granting of Roles to other Users

The main simplification is that weather or not a user can grant roles (authorities) to other users is no longer dependent on the authorities of both users. Instead the "can grant list" is the sole requirement.

Granting would be based on two properties linked to the user that wants to grant:

• can use authorities (aggregate list of authorities from a user's roles)
• can grant roles (aggregate list of roles a user can grant from the user and/or the user's roles)

It is easy to see how power can be delegated and that power has to be granted down from a user that is allowed to grant it. It is a tree "graph" with no loops.
It also allows to model users that can grant specific roles/authorities while holding much more authorities to use. This is another major issue with the current system where the need to use authority always also implies it can potentially be granted to others.

Removing "can grant" roles becomes the tricky bit so solve. Either this is simply limited to the ALL user alone, self removal or some logic. But such logic would realistically walk into similar issues of comparing authorities between the two involved users where unwanted locked in issues may arise. Therefore it might be wise to instead simply have a dedicated authority to remove authorities from others.

Another open question is which object should best hold the "can grant" list. Such a list might be associated with the user and/or user roles. Alternatively it could even be associated with a specific authority. Then such an authority is effectively the authority to grant certain roles. But in the current persistence model we would have no place to persist this as authorities are no object type on their own. This is mentioned anyhow since they might become one in a remodeled authority system.