[PM-12473] refactor: add CollectionAuthorizationService and wire it into the Update endpoint

[r-tome]

🎟️ Tracking

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

📔 Objective

We are replacing BulkCollectionAuthorizationHandler with per-resource [Resource]AuthorizationService classes. Each service fetches its own data. Each service calls a shared static Rules class.

An earlier design used ASP.NET's IAuthorizationHandler. It made the controller fetch data first, then pass it to the handler. A reviewer flagged this problem on PR #8075. We dropped that design.

This PR adds the first service: ICollectionAuthorizationService. It has three methods:

• AuthorizeUpdateAsync checks one collection. PUT organizations/{orgId}/collections/{id} calls it now, behind the pm-35160-authorization-services flag. The old handler check stays as the fallback.
• AuthorizeModifyUserAccessManyAsync and AuthorizeModifyGroupAccessManyAsync check a batch of collections. No controller calls them yet. A follow-up PR will wire them into CollectionsController.PostBulkCollectionAccess. Later PRs will wire them into GroupsController and OrganizationUsersController.

The service calls a static CollectionRules class, split into two tiers:

• OrganizationWide: rules that apply to every collection in the org (CanUpdate, CanModifyUserAccess, CanModifyGroupAccess).
• PerCollection: the fallback for one collection. The caller manages that collection, or the caller is an Owner/Admin and the collection is orphaned.

This PR also fixes a bug. CanModifyGroupAccess checked Permissions.ManageUsers. It now checks Permissions.ManageGroups.

CollectionAuthorizationService matches the old handler in three ways:

• It memoizes lookups for the life of the request, like the old handler.
• A non-member skips straight to the provider-user check.
• An unknown or cross-org collection ID is left out of the result, not treated as authorized. An empty request returns an empty result.

📸 Screenshots

N/A

[codecov]

Codecov Report

❌ Patch coverage is 93.39623% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.33%. Comparing base (6fbf0f2) to head (51e2291).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
...tion/Collections/CollectionAuthorizationService.cs	91.56%	4 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8211      +/-   ##
==========================================
+ Coverage   63.22%   63.33%   +0.10%     
==========================================
  Files        2381     2385       +4     
  Lines      103757   104002     +245     
  Branches     9385     9426      +41     
==========================================
+ Hits        65604    65867     +263     
+ Misses      35924    35888      -36     
- Partials     2229     2247      +18     

☔ 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

Re-reviewed at head commit 51e2291e3. The new CollectionAuthorizationService was traced against BulkCollectionAuthorizationHandler for all three operations (update metadata, modify user access, modify group access) and the authorization outcomes match for every role/permission combination, including the non-member provider-user path and the orphaned-collection fallback. The Put endpoint change is gated behind pm-35160-authorization-services with the existing handler retained as the fallback, and unit coverage across CollectionRulesTests, CollectionAuthorizationServiceTests, and CollectionsControllerTests exercises both branches.

No findings.

Code Review Details

Verification notes from this pass:

• Previously open finding is resolved. The orphaned-collections query is now gated on hasUnmanagedCollections && CollectionRules.PerCollection.CanManageOrphanedCollections(organization) (src/Api/AdminConsole/Authorization/Collections/CollectionAuthorizationService.cs:65-69), restoring the short-circuit and covered by AuthorizeUpdateAsync_WhenOwnerManagesCollectionDirectly_SkipsOrphanedCollectionsQuery.
• Apparent rule divergence is unreachable. The old handler let Permissions.EditAnyCollection custom users manage orphaned collections, while PerCollection.CanManageOrphanedCollections restricts that to Owner/Admin. For all three operations EditAnyCollection already grants authorization at the OrganizationWide tier, so the per-collection branch is never reached with that permission. No behavior change.
• Org scoping is tightened, not loosened. The old handler derived the target org from the resource (resources.First().OrganizationId) and ignored the route orgId; the new service filters requested IDs to the route organizationId. A cross-org PUT now returns 404 instead of proceeding. This is documented in the ICollectionAuthorizationService remarks and is a security improvement.
• Provider-user bypass preserves the previous all-or-nothing semantics, and the query is skipped entirely when every requested collection is already authorized.
• DI registration uses TryAddScoped per ADR 0026, and scoped lifetime matches the per-request memoization the service relies on.
• New files correctly omit #nullable enable — Directory.Build.props sets Nullable=enable for non-test projects.

[claude]

🎨 SUGGESTED: The orphaned-collections query runs for every Owner/Admin, even when callerManagedCollectionIds already authorizes all requested collections.

Details and fix

GetOrphanedCollectionIdsAsync calls Collection_ReadWithGroupsAndUsersByOrganizationId, which returns every collection in the organization plus every CollectionGroup and CollectionUser row for it — three result sets, then an O(collections × groups) FirstOrDefault join in Infrastructure.Dapper/AdminConsole/Repositories/CollectionRepository.cs:115.

BulkCollectionAuthorizationHandler.CanManageCollectionsAsync only reached that query after the managed-collection check had already failed:

var canManageTargetCollections = targetCollections.All(tc => _managedCollectionsIds.Contains(tc.Id));
if (canManageTargetCollections)
{
    return true;   // orphaned query never runs
}

Here the CanManageOrphanedCollections gate only filters out non-Owner/Admin callers, so the most common admin path — an Owner or Admin in an organization with AllowAdminAccessToAllCollectionItems = false editing a collection they are directly assigned to manage — now pays for the full-organization access read on every call, where it previously paid nothing.

Adding the managed-collection check to the gate restores the old short-circuit:

var callerManagedCollectionIds = await GetCallerManagedCollectionIdsAsync(currentContext.UserId.Value);
var hasUnmanagedCollections = requestedCollectionIds.Any(id => !callerManagedCollectionIds.Contains(id));
// Only Owners and Admins can manage orphaned collections, and only unmanaged collections need the check.
var orphanedCollectionIds = hasUnmanagedCollections && CollectionRules.PerCollection.CanManageOrphanedCollections(organization)
    ? await GetOrphanedCollectionIdsAsync(organizationId)
    : new HashSet<Guid>();

This matters more once GroupsController and OrganizationUsersController are wired to the batch methods, since those save paths are higher volume than a collection PUT.