Suport for Repository Authentication

[msymons]

Current Behavior:

Dependency-Track implemented support for:

• Configuration of "Internal Components" in v3.7 (OSS Index: Allow exclusion of components to scan #303)
• Configurable respositories in v3.8 (Make repositories configurable #164)

Configurable repositories were implemented as an MVP and do not yet support authentication. This makes it impossible to make use of internal repositories that enforce authentication (Nexus Repository Manager, etc) and also of external repos that do the same (such as Oracle).

One impact of not being able to connect to an internal repository would be to not have access to "current version" information for internal components. Current simple UI display of "current version" is already very useful, but DT v4.2 milestone contains an issue for "Add support for component age in policy conditions" (#772) and internal components should not be excluded from such policies.

Proposed Behavior:

Extend functionality of configurable repositories to support authentication.

[nscuro]

Just curious, would basic auth be the only AuthN method that must be considered? Are there any known examples of repos that use "non-standard" methods, like custom HTTP headers, query params etc.?

[stevespringett]

Docker and NPM both use realms and tokens with custom endpoints. Both also support BASIC but which can be disabled leaving only the repo-specific auth functional.

For MVP, I think BASIC should suffice. That should cover the majority of use cases. If a repo doesn't end up supporting BASIC but something else, I think DT should support it. But I also think that if a repo supports BASIC in addition to something else and BASIC is disabled, then supporting that something else will be prioritized as p3 or flagged with help wanted.

[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.