Policy: MatchSubjectMappings should be operator agnostic

[jakedoublev]

Background

At time of original implementation, there were two logical operators within Subject Condition Sets' Conditions: IN and NOT_IN. It was documented at the time that there were known performance concerns around a platform being driven to give granular access instead of ABAC. For example, if an admin utilized a specific widely used selector within the entitlement conditions of policy, like an entity representation field .emailAddress which every person entity would likely have, every condition would need to be resolved for every user.

As a result, the database query was given matching logic to check IN/NOT_IN presence along with the field when identifying matched subject mappings. This reduced the performance concern because a platform admin's poor use of selectable fields could return every subject mapping for every request. The idea was that this policy API could return all possible matches for an entity but would not do the logic of applying any logic on the conditions to determine true entitlement (leaving that to Authorization Service).

However, maturing of the platform led to the additional operator being added IN_CONTAINS, and it is known there may be likely future operators STARTS_WITH and ENDS_WITH.

These operators are not supported by the current API implementation. This has not been a problem because MatchSubjectMappings is not used internally within the platform and no consumers of the platform have reported this behavior as an issue.

Within Authorization Service, the operators mean:

• NOT_IN: entity has the selector field on their entity representation but it DOES NOT resolve to one of the specified values in the list
• IN: entity has the selector field on their entity representation AND it resolves to one of the values in the list
• IN_CONTAINS: entity has the selector field on their entity representation AND its value contains one of the substrings specified in the list

In all cases above, including NOT_IN, the entity representation logically resolved contains the selector field to be applied by the operator. In other words, given an entity representation for entityA containing solely {"id":"myUniqueId"} and a (simplified) condition of {"selectorField":".group","operator":"NOT_IN","values":["anyGroup"]}, the entity does not resolve to true under the condition alone because group is not present. NOT_IN means the field is there the values are not present rather than the field is not there so the values are not present.

Acceptance Criteria

1. MatchSubjectMappings is driven by purely entity selector fields and not values
2. Documentation in the database code and in the proto comments clarifies this behavior
3. policy integration tests are updated