Skip to main content

Collection Policy Assignment

This page documents Zerq client governance tied to profile and policy controls.

What to configure​

  • Define the client identifier used as X-Client-ID.
  • Map each client to allowed profiles (X-Profile-ID) and collections.
  • Attach policy rules for route/method constraints and optional rate tiers.

Validation steps​

  1. Verify allowed route/method succeeds with expected headers and auth.
  2. Verify disallowed method returns 405 or 403 based on policy design.
  3. Verify cross-collection access is denied for the same client.
  4. Check audit logs include admin actor and changed client binding.

Example scenario​

Scenario: assign a partner client to a single collection with constrained methods.

curl -i https://gateway.example.com/inventory/items \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: partner-erp" \
  -H "X-Profile-ID: partner-prod"

If partner-erp is not bound to the selected profile or collection, Zerq should return 403 and record the deny reason in request logs.

Evidence to capture​

  • Policy decision records tied to X-Client-ID and X-Profile-ID.
  • Authentication reason codes for denied requests (401 vs 403).
  • Final profile-policy mapping used by the request.

Extra negative test​

Use a valid Authorization token with a client ID not bound to the profile. Zerq should deny with 403 and log a client-profile mismatch.

Rollback checkpoint​

If policy updates over-block traffic, restore the previous client/profile binding set and retest one approved path and one denied path before reapplying finer-grained rules.