[PM-40211] Authorize Access Rule endpoints with IOrganizationRequirement

[Hinton]

🎟️ Tracking

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

📔 Objective

Declarative authorization on the access-rule routes (ADR-0022): reads require organization membership, writes require authority over rule authorship via the new ManageAccessRulesRequirement.

Worth flagging for review:

• Deviation: no named-policy bridge. The story specifies policy-name constants in Policies.cs registered in Api/Startup.cs, because Pam.csproj cannot reference Api and so could not reach AuthorizeAttribute<T>. PM-41272 has since extracted that code into src/Libraries/OrganizationAuthorization, which depends only on Core — so Pam references the library directly and attaches requirements per route. Policies.cs and Startup.cs are untouched.
• Requirements combine with, not replace, the group policy. They're carried as endpoint metadata, which AuthorizationMiddleware combines with the group-level Policies.Application; a test asserts both are present on every route. OrganizationRequirementHandler resolves the org from the {orgId:guid} group prefix and is already DI-registered.
• Scope: the Access Rule half only. The usage gate on access-request submission (which must check the member's AccessPam and the org's UsePam) and the CipherLeaseGate parity decision cannot land yet — SubmitAccessRequestCommand does not exist on main, since the access-request and cipher-lease handlers are still NotImplementedException scaffolds. There is no submission path to gate; that work belongs with the request/lease behaviour slices. For the same reason there were no imperative EnsureMemberAsync/EnsureAdminAsync checks to delete — AccessRuleEndpointsHandler never had them on main. PM-40211 should stay open for the remaining half.
• The two observable changes flagged in breakdown review note 8 hold here: unauthorized calls return 403 from the middleware rather than 404 from a handler, and BasePermissionRequirement/MemberOrProviderRequirement authorize provider users.

Lockfile changes are the new project reference only — no platform churn.

Depends on #8160 and #8161 — review those first.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.07%. Comparing base (b937e2f) to head (0356bd4).

Additional details and impacted files

@@                   Coverage Diff                    @@
##           pam/enable-pam-flows    #8162      +/-   ##
========================================================
- Coverage                 67.53%   63.07%   -4.46%     
========================================================
  Files                      2315     2315              
  Lines                    100561   100566       +5     
  Branches                   9052     9052              
========================================================
- Hits                      67910    63431    -4479     
- Misses                    30364    34944    +4580     
+ Partials                   2287     2191      -96     

☔ 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.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the declarative authorization added to the PAM access-rule routes: a group-level MemberRequirement plus ManageAccessRulesRequirement on the three write endpoints, the new ManageAccessRulesRequirement in PermissionRequirements.cs, and the OrganizationAuthorization project reference from Pam.csproj. Verified that Permissions.ManageAccessRules and its claim already exist, that OrganizationRequirementHandler is DI-registered in Api via AddAuthorizationHandlers(), that the {orgId:guid} group prefix satisfies HttpContextExtensions.GetOrganizationId(), and that ASP.NET's AuthorizationPolicy.CombineAsync accumulates the group's Policies.Application with the per-endpoint requirement metadata rather than replacing it — matching what the new tests assert. Lock files are consistent with the single project-reference addition across all six affected manifests; no new NuGet packages, so no AppSec dependency approval is required.

Code Review Details

No blocking findings.

Notes considered and intentionally not raised as findings:

• Reads being gated at plain organization membership is stated as the intended design in the PR description, and the handlers are still NotImplementedException scaffolds, so there is no live data exposure.
• A provider user who is also an org member would pass both gates on writes; this is inherent to BasePermissionRequirement's provider fallback across all existing consumers, not introduced here.
• The group documents 400/404 in OpenAPI but not 401/403; a documentation-only gap.

[eliykat]

This suggests that you don't actually want to reuse BasePermissionRequirement because you don't want to authorize providers. It works for most of our custom permissions, but you can always implement IOrganizationRequirement directly if you don't want that behavior.

For example:

public class ManageAccessRulesRequirement : IOrganizationRequirement
{
    public Task<bool> AuthorizeAsync(CurrentContextOrganization? organizationClaims,
        Func<Task<bool>> isProviderUserForOrg)
    {
        var authorized = organizationClaims is
            { Type: OrganizationUserType.Owner }
            or { Type: OrganizationUserType.Admin }
            or { Type: OrganizationUserType.Custom, Permissions.ManageAccessRules : true };

        return Task.FromResult(authorized);
    }
}

This can be used inside Authorize<T> in the same way, so no change to the consumers.

You can own this requirement if desired, because it reflects the authorization rules for your domain.