Implement Portfolio Access Control - Part 2

[stevespringett]

Ticket #140 describes the initial support for Portfolio ACLs (beta) and covers the majority of cases. However, there are known gaps and these gaps will be implemented in this ticket.

Known gaps include:

• AnalysisResource
• NotificationRuleResource
• PolicyResource
• SearchResource
• ViolationAnalysisResource

In addition, all resources where ACL logic is performed, should include a notification in the audit log for tracking purposes. This will be implemented as part of this enhancement.

[stevespringett]

Moving out a release to (hopefully) get feedback from the ACL logic introduced in v4.3. So far, no positive or negative feedback.

[nibiwodong]

I expect flexible permission configuration policies :)
I think there are three method:

• Configure user or group permissions for a certain project
  In project page, user can config this project auth user or group.
• Configure project permissions for a certain users
  in Portfolio Access Control module, user can config project permission to a certain user
• Configure project permissions for a certain group, It's already done I think
  in Portfolio Access Control module, user can config project permission to a certain group

[CBerndt-Work]

First tests look good.

I noticed, that if access control is enabled and a user has the PORTFOLIO_MANAGEMENT permission, they can create a new project but are not automatically added to its ACL and therefore cannot interact with it.
As it currently stands a user that needs to create projects has to also have the ACCESS_MANAGEMENT permission when access control is enabled or ask a user with that permission to alter the ACL for the new project.
To fix this I propose, that the user should be enabled to provide one or more of their teams that should be added to the projects ACL at creation.

I also think it would be useful to add a project owner. That project owner would then be given ACCESS_MANAGEMENT within the scope of their project as proposed by @nibiwodong . The initial project owner would be the creator of the project.
That would move the responsibility to manage project access away from the system administrator to the project responsible.
As a nice side effect it would also provide an easy way to identify the information owner, which is a requirement in some corporate environments.

[black-snow]

I need devs to be able to edit missing license information to components. Apparently, this requires portfolio mgmt permissions, which in turn allow almost everything ...

A fine grained control would be pretty much needed.

[krizon]

Are there any plans to work on this issue in the near future? We're looking into using DependencyTrack but we need to be able to have a clear distinction between different teams and locations.

The "Portfolio Access Control" currently facilitates this only partly because the ACLs aren't implemented within all resources. Especially the issues with metrics (#1682) is something that popups straight away once one start to work with "Portfolio Access Control".

[Gepardgame]

I noticed, that if access control is enabled and a user has the PORTFOLIO_MANAGEMENT permission, they can create a new project but are not automatically added to its ACL and therefore cannot interact with it. As it currently stands a user that needs to create projects has to also have the ACCESS_MANAGEMENT permission when access control is enabled or ask a user with that permission to alter the ACL for the new project. To fix this I propose, that the user should be enabled to provide one or more of their teams that should be added to the projects ACL at creation.

I made a specific issue for that 4092.
I also have provided PRs for both repositories to fix this issue.

[nscuro]

I need devs to be able to edit missing license information to components. Apparently, this requires portfolio mgmt permissions, which in turn allow almost everything ...

We recently got a contribution to Hyades which "deconstructs" the existing permissions into separate CRUD permissions: DependencyTrack/hyades#1406

This allows assigning of PORTFOLIOMANAGEMENT_UPDATE permissions for example, preventing creation or deletion.

Another contribution added the display of assigned teams to the Projects list: DependencyTrack/hyades#1435

Especially the issues with metrics (#1682) is something that popups straight away once one start to work with "Portfolio Access Control".

I believe the only piece we're missing here is a clever SQL query to calculate Portfolio metrics on-the-fly, based on which projects the authenticated user has access to.

In Hyades, metrics calculation was already moved to stored procedures. The calculation of portfolio metrics is here: https://github.com/DependencyTrack/hyades-apiserver/blob/e70776688f2040d0a521c3df9c2a856557e224b4/src/main/resources/migration/procedures/procedure_update-portfolio-metrics.sql#L41-L75

Perhaps it can act as a starting point for the mentioned ad-hoc query. The query needs to support arbitrary time ranges, since users will request portfolio metrics for the last X days, for example.

Are there any plans to work on this issue in the near future? We're looking into using DependencyTrack but we need to be able to have a clear distinction between different teams and locations.

I'd like to mention that any new resources we add, both for DT v4.x and Hyades, have portfolio ACL in mind. For example in the recent work on tags (#3881, #3894, #3896, #3924). Contributions to address holes in existing endpoints would be highly appreciated.