Feature
#4199
Describe the task
This change adds support for adding conditional matching for rules. Currently, a Rule matches based on entityType, entityTag, and operation and permission allow operation is set to true or false.
The rule is completely redesigned as follows:
- Rule matches on a set of resources instead of a single entity. To match all resources
all can be used.
- Rule matches on a set of operations instead of a single operation. To match all operations
all can be used.
- Rule has a new
condition where Spring Expression (SpEL) based condition can be passed. Example - isOwner() or isOwner() || noOwner().
- Rule now allows
effect which can either allow or deny an operation. Deny rules from all the relevant policies are executed first and the operation is denied if the rules evaluate to deny. Then all the remaining rules from all the relevant policies are executed and the operation is allowed if the rules evaluate to allow. Finally, the operation is not allowed if there are no rule matches.
jeasy rules are no longer used. Instead, policy evaluator is reimplemented and uses SpEL to provide rich conditions.
Computing list of policies for access control:
- First, all the policies of a user's role are evaluated for deny.
- Followed by the policies from the
defaultRoles of a team user belongs to and the policies directly attached to the team the user belongs to. Similarly, the policies of the entire team hierarchy user belongs to are evaluated.
With hierarchical policies, the following changes are being:
- Organizational policies are added to allow many default operations. With this, allowing all operations for an owner on the entity he/she owns is no longer hard coded and is part of organizational policy.
- All users have Organization as the default team when they don't belong to any team. Also, all the teams have Organization as the default parent when they don't have any parent.
Feature
#4199
Describe the task
This change adds support for adding conditional matching for rules. Currently, a
Rulematches based onentityType,entityTag, andoperationand permission allow operation is set totrueorfalse.The rule is completely redesigned as follows:
allcan be used.allcan be used.conditionwhere Spring Expression (SpEL) based condition can be passed. Example -isOwner()orisOwner() || noOwner().effectwhich can either allow or deny an operation. Deny rules from all the relevant policies are executed first and the operation is denied if the rules evaluate to deny. Then all the remaining rules from all the relevant policies are executed and the operation is allowed if the rules evaluate to allow. Finally, the operation is not allowed if there are no rule matches.jeasyrules are no longer used. Instead, policy evaluator is reimplemented and usesSpELto provide rich conditions.Computing list of policies for access control:
defaultRolesof a team user belongs to and the policies directly attached to the team the user belongs to. Similarly, the policies of the entire team hierarchy user belongs to are evaluated.With hierarchical policies, the following changes are being: