[jira] [Created] (RANGER-5845) Supported-constraint registration: deny access when a returned constraint is not supported by the caller

["Vyom Mani Tiwari (Jira)" <ji...@apache.org>]

Vyom Mani Tiwari created RANGER-5845:
----------------------------------------

             Summary: Supported-constraint registration: deny access when a returned constraint is not supported by the caller
                 Key: RANGER-5845
                 URL: https://issues.apache.org/jira/browse/RANGER-5845
             Project: Ranger
          Issue Type: Improvement
          Components: Ranger
            Reporter: Vyom Mani Tiwari
            Assignee: Vyom Mani Tiwari


RANGER-5842 adds constraint-policy evaluation: when access is allowed, the policy engine returns all matching constraints in {{{}RangerAccessResult.getConstraintResults(){}}}. If a caller can’t enforce a returned constraint (for example {{{}requireApproval{}}}), it might silently ignore it. This sub-task adds a way for plugins and PDP callers to declare which constraints they support. If a returned constraint isn’t supported, the result becomes a deny.

_Proposed behavior_
 * A plugin registers the names of the constraints it supports.
 * After constraint evaluation in {{{}RangerPolicyEngineImpl.evaluateConstraintPolicies{}}}, if any matched constraint isn’t in the supported set:
 ** the result becomes a deny ({{{}isAllowed=false{}}}) with reason {{{}unsupported constraint: <name>{}}};
 ** the constraint results are cleared;
 ** the deny is audited, with the policy id of the constraint policy.
 * When nothing is registered, the plugin supports no constraints, so it fails closed.
 * A service with no constraint policies behaves as today.

_Open questions (for discussion before implementation)_
 # *Registration mechanism:* a {{RangerBasePlugin}} API (e.g. {{{}setSupportedConstraints(Set<String>){}}}), a per-service property (e.g. {{{}ranger.plugin.<service>.supported.constraints=requireApproval,maxRows{}}}), or both? Proposal: both, with config overriding the API.
 # *Default when nothing is registered:* support none, so any returned constraint is denied? Proposal: yes.
 # *PDP / authz-api callers:* a shared PDP serves many callers, so a per-plugin set doesn’t fit. Should callers declare support per request (e.g. {{{}context.supportedConstraints{}}}), or per service in the PDP configuration? Proposal: a request field, falling back to PDP config.

_Out of scope:_ Admin storage and validation of constraint policies, audit schema changes beyond the deny reason, UI, and the authz-api response format (separate sub-tasks).

_Testing:_ policy-engine JSON tests for:
 * a supported constraint, which is allowed and returns its constraints;
 * an unsupported constraint, which is denied with the reason;
 * nothing registered, which is denied;
 * a mix of supported and unsupported constraints, which is denied;
 * no constraint policies, which leaves behavior unchanged;
 * config and API registration, including precedence.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)