Not allowed to upload sbom to project I create.

[JorisVanEijden]

Current Behavior:

As a team with BOM_UPLOAD and PROJECT_CREATION_UPLOAD permissions
When uploading a new sbom with autoCreate=true
I get an error "Access to the specified project is forbidden"
The project is created, but the sbom is not uploaded.

Expected Behavior:

As a user or team with BOM_UPLOAD and PROJECT_CREATION_UPLOAD permissions
When uploading a new sbom with autoCreate=true
I want the newly created project to be added to my allowed list of projects
so that the bom upload succeeds.

Environment:

• Dependency-Track Version: v4.4.1
• Distribution: Docker
• BOM Format & Version: json 1.4
• Database Server: PostgreSQL
• Browser: Brave

[rkg-mm]

Same happens with PORTFOLIO_MANAGEMENT permission and cloning a project. I can clone it via API but then not access the new project to upload a SBOM, which then fails the build pipeline.

See also my discussion here #1425 which is the result of this problem

[JorisVanEijden]

Looks like there is already a TODO in the code for this:

dependency-track/src/main/java/org/dependencytrack/resources/v1/BomResource.java

Line 271 in baa2f37

//TODO - If portfolio access control is enabled, retrieve the principal (ApiKey only) and automatically grant access to the project to the team the key belongs to.

and there should be one here too:

dependency-track/src/main/java/org/dependencytrack/resources/v1/ProjectResource.java

Line 212 in baa2f37

project = qm.createProject(jsonProject, jsonProject.getTags(), true);

[valentijnscholten]

When a project is created via the API using an API Key, the solution is quite straightforward indeed. Give the Team access to the new Project.

But what to do when a user creates a new project via the UI or API. We update the ACL because it works solely on Teams.. A user can have 0 or more Teams, which one(s) should we add to the ACL?

We could

• add all the users teams, but this might be too many/broad
• update the project creation parameters to allow specification of one or more Teams to add to the Project ACL.
• extend the ACL to also work on users, which would need quite a big refactoring
• add an optional owner field to a project which always has access, but this might cause clutter for portfolio managers
• create a Team for each user, similar to what Gitlab does with groups. This would also allow users to have their own API Key.

[valentijnscholten]

Same happens with PORTFOLIO_MANAGEMENT permission and cloning a project. I can clone it via API but then not access the new project to upload a SBOM, which then fails the build pipeline.

See also my discussion here #1425 which is the result of this problem

I think this is an issue of its own, so created one: #1534

[rkg-mm]

When a project is created via the API using an API Key, the solution is quite straightforward indeed. Give the Team access to the new Project.

But what to do when a user creates a new project via the UI or API. We update the ACL because it works solely on Teams.. A user can have 0 or more Teams, which one(s) should we add to the ACL?

I would say if a user creates it manually, he can (wants to?) also assign the groups manually. At least in my case I create the base of each project myself and assign the teams then. UI wise it would be nice this could be done already in the creation screen though. Currently First I need to create and then remember to assign in the admin menu.
But if there are use cases where a user creates a project and has no ACL permission, I'm not sure what to do.

[valentijnscholten]

The problem is that a user has no access to the project that is autocreated during BOM upload. If a user has ACCESS_MANAGEMENT permission, the user can do everything so there is no issue.

[rkg-mm]

The problem is that a user has no access to the project that is autocreated during BOM upload. If a user has ACCESS_MANAGEMENT permission, the user can do everything so there is no issue.

Yes autocreation by API is a problem. The only reasonable idea which I have, is that the API which allows autocreation also needs a parameter to supply group names for acl permissions. Logic wise that makes most sense (when I create a project I should be able to tell who gets access). But API wise that would be ugly. If the API should be "nicer" then the project needs the suggested "owner" field, so that the ACL API can be used either, if you have permission to modify ACL generally, or on projects on which you are the owner.

[valentijnscholten]

Yes, those suggestions are on the list above.
The problem also occurs when creating a project via the UI. The user creates a project, but won't be able to see it afterwards. The API, I think, is mainly used with API Keys which will belong to a Team and in #1529 the Team will have access to it when autocreating a Project.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.