[SM-378] Enable SM on a user basis

[Hinton]

Type of change

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

Objective

Adds support for enabling access to secrets manger on a per user basis. And adds checks to the list projects and secrets endpoints to verify access.

Left to add:

• Access checks for remaining endpoints

Code changes

• src/Api/Controllers/ProjectsController.cs: Check that the user has access to secrets manager on list projects.
• src/Api/Controllers/SecretsController.cs: Check that the user has access to secrets manager on list secrets.
• src/Api/Controllers/ServiceAccountsController.cs: Check that the user has access to secrets manager on list service accounts.
• src/Api/Models/Request/Organizations/OrganizationUserRequestModels.cs/ResponseModels.cs: Add AccessSecretsManager to request/response model (enables setting permission).
• src/Api/Models/Response/ProfileOrganizationResponseModel.cs: Include if the user has access to secrets manager in the sync response. Used to determine access in the client.
• src/Core/Context/CurrentContentOrganization.cs: Change current context to use OrganizationUserOrganizationDetails when building the scopes.
• src/Core/Context/CurrentContext.cs: Add AccessSecretsManager function on the CurrentContext used to determine if the user and org is allowed to access the secrets manager.
• src/Core/Entities/OrganizationUser.cs: Add AccessSecretsManager to the user table.
• src/Core/Identity/Claims.cs: Add a new claim for the jwt access.
• src/Core/Utilities/CoreHelpers.cs: Add support for building the claims for SM.
• src/Sql/dbo/*.sql: Update sprocs to support the new column.

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

[Hinton]

:/ Feels like there should be a better way to handle these things.

[cd-bitwarden]

Looks good to me, I definitely see that there will be a few conflicts when I merge this into my PR though 😅

I left a couple comments, nothing major just curious about 1 or 2 things.

[Thomas-Avery]

LGTM.

Any places we should use UnauthorizedAccessException or just use NotFoundException everywhere now?

[Hinton]

@Thomas-Avery I noticed we should have used forbidden but we don't have an exception for that and changed to not found. Open for re-adding forbidden though but it's a balance point between if we should disclose the existence of items you don't have permission to or just pretend they don't exists.

[Thomas-Avery]

Are we good with the stored proceduresOrganizationUser_CreateWithCollections that flows into OrganizationUser_Create not supporting the new flag?

Same question with OrganizationUser_UpdateWithCollections -> OrganizationUser_Update

[Hinton]

@Thomas-Avery not sure I follow, those are updated? https://github.com/bitwarden/server/pull/2590/files#diff-f74fe3dc4ae507f56ff7d9dfdfc3d3d0d3cdf13a7045020441bb2063b73fb9a0R21

[Thomas-Avery]

@Thomas-Avery not sure I follow, those are updated? https://github.com/bitwarden/server/pull/2590/files#diff-f74fe3dc4ae507f56ff7d9dfdfc3d3d0d3cdf13a7045020441bb2063b73fb9a0R21

My apologies, I must have been in the view that just showed the changes since my last review.

Approved