[PM-40336] Access Rules: API

[Hinton]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-40336

📔 Objective

Add the commercial CRUD API for org-scoped PAM Access Rules, consuming the
domain and persistence layer from #7981. This PR is stacked on #7981 — review
and merge that first; GitHub will retarget this PR to main once it lands.

All endpoints are gated behind the pm-37044-pam-v-0 (FeatureFlagKeys.Pam)
feature flag, so nothing is reachable in production until PAM v0 ships. Access-rule
data (name, description, conditions) is organization configuration metadata, not
Vault Data — no zero-knowledge surface is touched.

What's included

API — bitwarden_license/src/Services/Pam

• CRUD endpoints on the AccessRule group: GET (list), GET {id}, POST,
  PUT {id}, DELETE {id}, all org-scoped and feature-flag gated.
• Request/response models (AccessRuleRequestModel, AccessRuleResponseModel)
  and the condition models: human_approval and ip_allowlist.
• Create/Update/Delete commands behind interfaces; AccessRuleValidator
  validating the conditions JSON (max 10 conditions, per-type rules; empty list is
  vacuously valid and still routes access through PAM for audit).
• Command and validator unit tests.

📸 Screenshots

N/A — backend only.

---

Update: authorization now runs in the middleware

AccessRuleEndpointsHandler was hand-rolling ICurrentContext membership and admin
checks. Now that #8095 has landed on
main, Pam can reference src/Libraries/OrganizationAuthorization directly and
authorize the way controllers do — which is the follow-up that PR deliberately left
out ("Pam is not wired up here — that belongs with the endpoint changes that consume
it").

• MemberOrProviderRequirement on the group, matching the OrganizationUser check it
  replaces.
• A new ManageAccessRules custom permission, with ManageAccessRulesRequirement on
  POST/PUT/DELETE. ASP.NET combines the group and endpoint policies, so a write
  has to satisfy both.
• The rule.OrganizationId != orgId check stays in the handler — that is resource
  scoping, not authorization.
• /leases, /access-requests and /leases/ciphers/{id} are untouched: they carry no
  {orgId} in the route, so IOrganizationRequirement cannot bind.

Behaviour change: a non-member now gets 403 rather than the 404 the handler
used to throw. That matches every other organization-scoped endpoint in Api, and
these endpoints are unreleased and gated behind FeatureFlagKeys.Pam.

Important

@bitwarden/team-admin-console-dev — the first of the two new commits
(Add the ManageAccessRules custom permission) is AC-owned and PAM-free: it touches
Permissions, Claims, CurrentContext, OrganizationService, the
OrganizationAuthorization library, and the public API PermissionsModel. Happy to
split it into its own PR against main if you would rather review it separately.

Two parts of it are load-bearing rather than mechanical:

• The guard in OrganizationService.ValidateCustomPermissionsGrant — that path is an
  explicit per-permission if-chain, and without an entry a Custom member holding
  ManageUsers could grant a permission they do not hold themselves. The newer
  OrganizationUserValidationService walks ClaimsMap generically and needs no change.
• PermissionsModel carries the field in both directions, because the public API
  round-trips a member through it — omitting it would silently strip an existing grant
  on update.

No migration: Permissions is a JSON blob on OrganizationUser. Granting the permission
from the web vault still needs a matching toggle in bitwarden/clients; until that ships
the permission is never set, so Owners, Admins and providers retain exactly today's access.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the commercial CRUD API for org-scoped PAM Access Rules — the endpoint handler, request/response models, condition models, create/update/delete commands, and the shared write validator, plus their unit tests. Security-sensitive paths are sound: every endpoint is gated behind Policies.Application, the FeatureFlagKeys.Pam feature flag, and per-request org membership/admin checks, with rules scoped to orgId and 404s used to avoid leaking existence. Input validation (conditions JSON shape, condition count cap, CIDR parsing, name uniqueness, collection ownership/conflict) is thorough and well covered by the command and validator tests. Access-rule data is organization configuration metadata, not Vault Data, so no zero-knowledge surface is affected.

Code Review Details

No blocking findings.

Notes considered and not flagged:

• The handler's EnsureMemberAsync/EnsureAdminAsync authorization is already discussed in an open thread where the author proposes lifting it into RequireAuthorization; not duplicating here.
• DI registration uses AddScoped/AddSingleton rather than TryAdd*, matching the existing convention in ServiceCollectionExtensions.
• packages.lock.json changes reflect the internal Pam.Domain/Data project references added to Pam.csproj (transitive lock regeneration) — no new external dependency, no AppSec approval needed.

[codecov]

Codecov Report

❌ Patch coverage is 63.79310% with 105 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.80%. Comparing base (1ebb061) to head (c52178c).

Files with missing lines	Patch %	Lines
...Pam/Api/Models/Response/AccessRuleResponseModel.cs	0.00%	39 Missing ⚠️
...i/Endpoints/Handlers/AccessRuleEndpointsHandler.cs	0.00%	33 Missing ⚠️
...s/Pam/Api/Models/Request/AccessRuleRequestModel.cs	0.00%	18 Missing ⚠️
...e/src/Services/Pam/Services/AccessRuleValidator.cs	85.41%	4 Missing and 3 partials ⚠️
src/Core/Context/CurrentContext.cs	20.00%	4 Missing ⚠️
...s/Pam/Api/Models/Response/PamDateTimeExtensions.cs	0.00%	2 Missing ⚠️
.../Services/Pam/Services/AccessRuleWriteValidator.cs	95.65%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##           pam/access-rule    #7983      +/-   ##
===================================================
- Coverage            67.30%   62.80%   -4.51%     
===================================================
  Files                 2307     2315       +8     
  Lines               100433   100700     +267     
  Branches              9028     9052      +24     
===================================================
- Hits                 67599    63241    -4358     
- Misses               30553    35265    +4712     
+ Partials              2281     2194      -87     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eliykat]

AC was requested for review but it doesn't look like it's needed anymore. Let me know if I've misunderstood.

Agreed that we'll extract the authorization logic in #8095.