Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AC-1139] Flexible collections: deprecate Manage/Edit/Delete Assigned Collections custom permissions #3360

Merged
merged 141 commits into from
Dec 8, 2023

Conversation

r-tome
Copy link
Contributor

@r-tome r-tome commented Oct 19, 2023

Type of change

- [ ] Bug fix
- [X] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

Deprecate all Manager-related custom permissions:

  • Manage assigned collections
  • Edit assigned collections
  • Delete assigned collections

Code changes

Coupled with Clients PR (Still in progress)

  • src/Api/AdminConsole/Controllers/GroupsController.cs: If flexible collections feature flag is active then use the authorization service to check permissions on the Get endpoint
  • src/Api/AdminConsole/Controllers/OrganizationUsersController.cs: If flexible collections feature flag is active then use the authorization service to check permissions on the Get and GetDetails endpoints
  • src/Api/Utilities/ServiceCollectionExtensions.cs: Configure dependency injection for BulkCollectionAuthorizationHandler, GroupAuthorizationHandler and OrganizationUserAuthorizationHandler
  • src/Api/Vault/AuthorizationHandlers/Collections/BulkCollectionAuthorizationHandler.cs: Renamed the existing CollectionAuthorizationHandler to BulkCollectionAuthorizationHandler
  • src/Api/Vault/AuthorizationHandlers/Collections/CollectionAuthorizationHandler.cs: Created to handle logic for the ReadAll operation
  • src/Api/Vault/AuthorizationHandlers/Collections/CollectionOperations.cs: Added the operations Read, ReadAll and Update
  • src/Api/Vault/AuthorizationHandlers/Groups/GroupAuthorizationHandler.cs: Created to handle the authorization check for the ReadAll operation
  • src/Api/Vault/AuthorizationHandlers/Groups/GroupOperations.cs: Created the operation ReadAll for GroupAuthorizationHandler
  • src/Api/Vault/AuthorizationHandlers/OrganizationUsers/OrganizationUserAuthorizationHandler.cs: Created to handle the authorization check for the ReadAll operation
  • src/Api/Vault/AuthorizationHandlers/OrganizationUsers/OrganizationUserOperations.cs: Created the operation ReadAll for OrganizationUserAuthorizationHandler
  • src/Core/Context/CurrentContext.cs: Throwing FeatureUnavailableException on the the methods EditAssignedCollections, DeleteAssignedCollections and ViewAssignedCollections if the flexible collections feature flag is enabled
  • src/Core/Context/ICurrentContext.cs: Marked the methods EditAssignedCollections, DeleteAssignedCollections and ViewAssignedCollections as Obsolete
  • src/Core/Models/Data/Permissions.cs: Marked the properties EditAssignedCollections and DeleteAssignedCollections as Obsolete
  • src/Core/Services/ICollectionService.cs: Marked the method GetOrganizationCollectionsAsync as Obsolete
  • src/Core/Services/Implementations/CollectionService.cs: Altered the SaveAsync method that if the flexible collections feature flag is disabled then we set the users with EditAssignedCollections to manage the collection
  • src/Core/Services/Implementations/OrganizationService.cs: Altered the methods SaveUsersSendInvitesAsync and to set the collections with Manage = true if the user has EditAssignedCollections permission
  • src/Notifications/NotificationsHub.cs: Updated the CurrentContext constructor
  • test/Api.Test/Controllers/CollectionsControllerTests.cs: Updated the unit tests to test the new flexible collections logic
  • test/Api.Test/Vault/AuthorizationHandlers/BulkCollectionAuthorizationHandlerTests.cs: Renamed the existing tests file because the handler is now named BulkCollectionAuthorizationHandler
  • test/Api.Test/Vault/AuthorizationHandlers/CollectionAuthorizationHandlerTests.cs: Added unit tests for CollectionAuthorizationHandler
  • test/Api.Test/Vault/AuthorizationHandlers/GroupAuthorizationHandlerTests.cs: Added unit tests for GroupAuthorizationHandler
  • test/Api.Test/Vault/AuthorizationHandlers/OrganizationUserAuthorizationHandlerTests.cs: Added unit tests for OrganizationUserAuthorizationHandler
  • test/Core.Test/Services/CollectionServiceTests.cs: Testing the new logic to add Manage permissions to users with EditAssignedCollections
  • test/Core.Test/Services/OrganizationServiceTests.cs: Testing the new logic to add Manage permissions to users with EditAssignedCollections

Before you submit

  • Please check for formatting errors (dotnet format --verify-no-changes) (required)
  • If making database changes - make sure you also update Entity Framework queries and/or migrations
  • Please add unit tests where it makes sense to do so (encouraged but not required)
  • If this change requires a documentation update - notify the documentation team
  • If this change has particular deployment requirements - notify the DevOps team

differsthecat and others added 30 commits August 11, 2023 14:50
* Update sql files to add Manage permission

* Add migration script

* Rename collection manage migration file to remove duplicate migration date

* Migrations

* Add manage to models

* Add manage to repository

* Add constraint to Manage columns

* Migration lint fixes

* Add manage to OrganizationUserUserDetails_ReadWithCollectionsById

* Add missing manage fields

* Add 'Manage' to UserCollectionDetails

* Use CREATE OR ALTER where possible
* feat: update org table with new column, write migration, refs AC-1374

* feat: update views with new column, refs AC-1374

* feat: Alter sprocs (org create/update) to include new column, refs AC-1374

* feat: update entity/data/request/response models to handle new column, refs AC-1374

* feat: update necessary Provider related views during migration, refs AC-1374

* fix: update org create to default new column to false, refs AC-1374

* feat: added new API/request model for collection management and removed property from update request model, refs AC-1374

* fix: renamed migration script to be after secrets manage beta column changes, refs AC-1374

* fix: dotnet format, refs AC-1374

* feat: add ef migrations to reflect mssql changes, refs AC-1374

* fix: dotnet format, refs AC-1374

* feat: update API signature to accept Guid and explain Cd verbiage, refs AC-1374
…3194)

* [AC-1174] Introduce BulkAuthorizationHandler.cs

* [AC-1174] Introduce CollectionUserAuthorizationHandler

* [AC-1174] Add CreateForNewCollection CollectionUser requirement

* [AC-1174] Add some more details to CollectionCustomization

* [AC-1174] Formatting

* [AC-1174] Add CollectionGroupOperation.cs

* [AC-1174] Introduce CollectionGroupAuthorizationHandler.cs

* [AC-1174] Cleanup CollectionFixture customization

Implement and use re-usable extension method to support seeded Guids

* [AC-1174] Introduce WithValueFromList AutoFixtureExtensions

Modify CollectionCustomization to use multiple organization Ids for auto generated test data

* [AC-1174] Simplify CollectionUserAuthorizationHandler.cs

Modify the authorization handler to only perform authorization logic. Validation logic will need to be handled by any calling commands/controllers instead.

* [AC-1174] Introduce shared CollectionAccessAuthorizationHandlerBase

A shared base authorization handler was created for both CollectionUser and CollectionGroup resources, as they share the same underlying management authorization logic.

* [AC-1174] Update CollectionUserAuthorizationHandler and CollectionGroupAuthorizationHandler to use the new CollectionAccessAuthorizationHandlerBase class

* [AC-1174] Formatting

* [AC-1174] Cleanup typo and redundant ToList() call

* [AC-1174] Add check for provider users

* [AC-1174] Reduce nested loops

* [AC-1174] Introduce ICollectionAccess.cs

* [AC-1174] Remove individual CollectionGroup and CollectionUser auth handlers and use base class instead

* [AC-1174] Tweak unit test to fail minimally

* [AC-1174] Reorganize authorization handlers in Core project

* [AC-1174] Introduce new AddCoreAuthorizationHandlers() extension method

* [AC-1174] Move CollectionAccessAuthorizationHandler into Api project

* [AC-1174] Move CollectionFixture to Vault folder

* [AC-1174] Rename operation to CreateUpdateDelete

* [AC-1174] Require single organization for collection access authorization handler

- Add requirement that all target collections must belong to the same organization
- Simplify logic related to multiple organizations
- Update tests and helpers
- Use ToHashSet to improve lookup time

* [AC-1174] Fix null reference exception

* [AC-1174] Throw bad request exception when collections belong to different organizations

* [AC-1174] Switch to CollectionAuthorizationHandler instead of CollectionAccessAuthorizationHandler to reduce complexity
* [AC-1117] Add manage permission (#3126)

* Update sql files to add Manage permission

* Add migration script

* Rename collection manage migration file to remove duplicate migration date

* Migrations

* Add manage to models

* Add manage to repository

* Add constraint to Manage columns

* Migration lint fixes

* Add manage to OrganizationUserUserDetails_ReadWithCollectionsById

* Add missing manage fields

* Add 'Manage' to UserCollectionDetails

* Use CREATE OR ALTER where possible

* [AC-1374] Limit collection creation/deletion to Owner/Admin (#3145)

* feat: update org table with new column, write migration, refs AC-1374

* feat: update views with new column, refs AC-1374

* feat: Alter sprocs (org create/update) to include new column, refs AC-1374

* feat: update entity/data/request/response models to handle new column, refs AC-1374

* feat: update necessary Provider related views during migration, refs AC-1374

* fix: update org create to default new column to false, refs AC-1374

* feat: added new API/request model for collection management and removed property from update request model, refs AC-1374

* fix: renamed migration script to be after secrets manage beta column changes, refs AC-1374

* fix: dotnet format, refs AC-1374

* feat: add ef migrations to reflect mssql changes, refs AC-1374

* fix: dotnet format, refs AC-1374

* feat: update API signature to accept Guid and explain Cd verbiage, refs AC-1374

* feat: created collection auth handler/operations, added LimitCollectionCdOwnerAdmin to CurrentContentOrganization, refs AC-1125

* feat: create vault service collection extensions and register with base services, refs AC-1125

* feat: deprecated CurrentContext.CreateNewCollections, refs AC-1125

* feat: deprecate DeleteAnyCollection for single resource usages, refs AC-1125

* feat: move service registration to api, update references, refs AC-1125

* feat: add bulk delete authorization handler, refs AC-1125

* feat: always assign user and give manage access on create, refs AC-1125

* fix: updated CurrentContextOrganization type, refs AC-1125

* feat: combined existing collection authorization handlers/operations, refs AC-1125

* fix: OrganizationServiceTests -> CurrentContentOrganization typo, refs AC-1125

* fix: format, refs AC-1125

* fix: update collection controller tests, refs AC-1125

* fix: dotnet format, refs AC-1125

* feat: removed extra BulkAuthorizationHandler, refs AC-1125

* fix: dotnet format, refs AC-1125

* fix: change string to guid for org id, update bulk delete request model, refs AC-1125

* fix: remove delete many collection check, refs AC-1125

* fix: clean up collection auth handler, refs AC-1125

* fix: format fix for CollectionOperations, refs AC-1125

* fix: removed unnecessary owner check, add org null check to custom permission validation, refs AC-1125

* fix: remove unused methods in CurrentContext, refs AC-1125

* fix: removed obsolete test, fixed failling delete many test, refs AC-1125

* fix: CollectionAuthorizationHandlerTests fixes, refs AC-1125

* fix: OrganizationServiceTests fix broken test by mocking GetOrganization, refs AC-1125

* fix: CollectionAuthorizationHandler - remove unused repository, refs AC-1125

* feat: moved UserId null check to common method, refs AC-1125

* fix: updated auth handler tests to remove dependency on requirement for common code checks, refs AC-1125

* feat: updated conditionals/comments for create/delete methods within colleciton auth handler, refs AC-1125

* feat: added create/delete collection auth handler success methods, refs AC-1125

* fix: new up permissions to prevent excessive null checks, refs AC-1125

* fix: remove old reference to CreateNewCollections, refs AC-1125

* fix: typo within ViewAssignedCollections method, refs AC-1125

---------

Co-authored-by: Robyn MacCallum <robyntmaccallum@gmail.com>
* [AC-1174] Update SelectionReadOnlyRequestModel to use Guid for Id property

* [AC-1174] Introduce initial bulk-access collection endpoint

* [AC-1174] Introduce BulkAddCollectionAccessCommand and validation logic/tests

* [AC-1174] Add CreateOrUpdateAccessMany method to CollectionRepository

* [AC-1174] Add event logs for bulk add collection access command

* [AC-1174] Add User_BumpAccountRevisionDateByCollectionIds and database migration script

* [AC-1174] Implement EF repository method

* [AC-1174] Improve null checks

* [AC-1174] Remove unnecessary BulkCollectionAccessRequestModel helpers

* [AC-1174] Add unit tests for new controller endpoint

* [AC-1174] Fix formatting

* [AC-1174] Remove comment

* [AC-1174] Remove redundant organizationId parameter

* [AC-1174] Ensure user and group Ids are distinct

* [AC-1174] Cleanup tests based on PR feedback

* [AC-1174] Formatting

* [AC-1174] Update CollectionGroup alias in the sproc

* [AC-1174] Add some additional comments to SQL sproc

* [AC-1174] Add comment explaining additional SaveChangesAsync call

---------

Co-authored-by: Thomas Rittson <trittson@bitwarden.com>
* Rename LimitCollectionCdOwnerAdmin -> LimitCollectionCreationDeletion

* Rename and bump migration script
…cks (#3301)

* fix: remove EditAnyCollection from Create/Delete permission check, refs AC-1666

* fix: updated comment, refs AC-1666
…aveAsync(...) (#3312)

* fix: remove AssignUserId from CollectionService.SaveAsync, refs AC-1669

* fix: add manage access conditional before creating collection, refs AC-1669

* fix: move access logic for create/update, fix all tests, refs AC-1669

* fix: add CollectionAccessSelection fixture, update tests, update bad reqeuest message, refs AC-1669

* fix: format, refs AC-1669

* fix: update null params with specific arg.is null checks, refs Ac-1669

* fix: update attribute class name, refs AC-1669
@eliykat
Copy link
Member

eliykat commented Dec 1, 2023

Oh, and @shane-melton still needs to review 😁

@r-tome
Copy link
Contributor Author

r-tome commented Dec 1, 2023

Thanks for that summary of the situation to test, its really helpful!
I cannot test that yet because there is an issue on clients that prevents a user with Manage permission to assign another user to the collection (this.manage undefined issue).

I have revised BulkOperations.Read to not require Manage permission because a user with Edit permission still needs to access it. Or are we changing clients to not load the users tab on a collection?

Copy link
Member

@shane-melton shane-melton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partial review for now, I will finish up more tomorrow. It looks pretty good, just a couple questions surrounding the new Read collection authorization requirement methods.

@r-tome
Copy link
Contributor Author

r-tome commented Dec 5, 2023

@shane-melton and @eliykat thank you again for the reviews, all problems mentioned in the reviews have been addressed.

The situation to test would be:
User role in the organization
canManage permission in 1 collection
LimitCollectionCreationDeletion set to true
try to add another user to your collection - at the moment I think you'll hit an error?

I tested this scenario and worked fine.

@r-tome
Copy link
Contributor Author

r-tome commented Dec 5, 2023

Btw, I agree this needs to be tested before merge so I've added the needs-qa tag

Copy link
Member

@shane-melton shane-melton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finished up my review and this looks good to go. Only saw two spots were the comments became out of date with the code and then just a general thought on how we name the authorization handlers. But, nothing that should be considered blocking from my perspective for this PR!

{
// Owners, Admins, and users with DeleteAnyCollection permission can always delete collections
// Owners, Admins, and users with EditAnyCollection, DeleteAnyCollection,
// or AccessImportExport permission can always read a collection
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This comment is out of date and is missing ManageGroups

CurrentContextOrganization? org)
{
// Owners, Admins, and users with EditAnyCollection permission can always manage collection access
// Owners, Admins, and users with EditAnyCollection or DeleteAnyCollection
// permission can always read a collection
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Same here, comment is missing ManageUsers

Copy link
Member

@shane-melton shane-melton Dec 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: After looking at these Collection authorization handlers some more, their names don't seem to clearly distinguish their differences all that well and might be confusing to those unfamiliar.

BulkCollectionAuthorizationHandler makes sense to me and implies that it can handle authorizing multiple collections at a once.

However, seeing CollectionAuthorizationHandler would then be a bit confusing because just by the name I wouldn't expect it to do anything different that the Bulk handler couldn't already do.

I'm not suggesting we need to necessarily make a change for this PR, but I'm curious to what you both think on this?

My suggestion to potentially clear it up would be to rename the CollectionAuthorizationHandler to something like OrganizationCollectionsAuthorizationHandler. I would prefix it with Organization because I think it could be argued that the Organization is the resource being examined here and not the Collections; especially because the current handler has no resource and is pulling the organization from the auth requirement anyways. Then you could simply pass the Organization in as the resource and the operation would simply by OrganizationCollectionOperations.ReadAll.

This could also be used as a pattern for other similar Organization focused operations like read all Groups or Users.

cc: @eliykat

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this was a subject of some discussion when I first did the proof of concept for this pattern for Groups.

I originally used Organization as the resource as you suggest @shane-melton, simply because there is no single "Collection" object to use as the resource instead. I think the objection there was that it split the auth handlers. However, that ended up happening anyway, just because the logic is sufficiently different. Also, embedding the orgId in the requirement still feels like a hack, and a bad pattern to establish.

So I think your suggestion is a good one, it's just a lot more straightforward. I'd like to do a bit of a retro on the handler pattern more generally once FC is done to review how it's going and whether we should make any changes to our approach before extending the pattern.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me! I'm all for revisiting the auth handler pattern again after FC and thanks for the extra context/history!

Also, embedding the orgId in the requirement still feels like a hack, and a bad pattern to establish.

Agreed!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rename the CollectionAuthorizationHandler to something like OrganizationCollectionsAuthorizationHandler. I would prefix it with Organization because I think it could be argued that the Organization is the resource being examined here and not the Collections

Absolutely! I struggle with naming and during the development of this branch both AuthorizationHandlers went through multiple versions. That's why some comments also require updating. I'm interested in exploring ways to eliminate OrgId from the requirement. Let's talk about this in one of our upcoming FC dev syncs.

@r-tome r-tome removed the needs-qa label Dec 8, 2023
@r-tome r-tome merged commit fb0c442 into master Dec 8, 2023
43 of 44 checks passed
@r-tome r-tome deleted the flexible-collections/deprecate-custom-collection-perm branch December 8, 2023 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants