alpine.enforce.authentication=false produces 404s

[nickwilliams-codynamic]

The defect may already be reported! Please search for the defect before creating one.

Current Behavior:

When setting the alpine.enforce.authentication and authorization properties to false, the webserver returns a 404 response for all URLs.

Additionally setting the propertise as environment variables seems to have no effect (e.g. ALPINE_ENFORCE_AUTHENTICATION still show the login screen)

Steps to Reproduce:

Set alpine.enforce.authentication to false. Sample docker-compose and properties file below

Expected Behavior:

The depedencytrack dashboard appears with no login screen prompted

Environment:

• Dependency-Track Version: latest (digest efc65e702ee1)
• Distribution: Docker
• BOM Format & Version: N/A
• Database Server: H2
• Browser: Firefox | Google Chrome

Additional Details:

docker-compose.yaml:

version: "3"
services:
  dependency-track:
    image: "owasp/dependency-track"
    command: java -XX:MaxRAMPercentage=90.0 -Dalpine.application.properties=/app/props/application.properties -DdependencyTrack.logging.level=INFO -jar dependency-track-embedded.war -context ${CONTEXT}
    ports:
      - 8080:8080
    volumes:
      - ./data:/data
      - ./props:/app/props/application.properties

NOTE: Use all other default properties from https://docs.dependencytrack.org/getting-started/configuration/ props/application.properties

############################ Alpine Configuration ###########################
# Optional
# When authentication is enforced, API keys are required for automation, and
# the user interface will prevent anonymous access by prompting for login
# credentials.
alpine.enforce.authentication=false

# Optional
# When authorization is enforced, team membership for both API keys and user
# accounts are restricted to what the team itself has access to. To enforce 
# authorization, the enforce.authentication property (above) must be true.
alpine.enforce.authorization=false

[stevespringett]

Those two properties are features of the Alpine framework. They are not currently supported by Dependency-Track.

Is this a defect report? If so, the response is 'works as designed'.

If this is an enhancement request, if so, what is the use case?

[nickwilliams-codynamic]

I did think it was a defect report, but I must have misunderstood. I had assumed that with these settings set to false, I could access the dependencytrack dashboard anonymously. However with the properties set to false the UI never loads.

# When authentication is enforced, API keys are required for automation, and
# the user interface will prevent anonymous access by prompting for login
# credentials.

If this is indeed working as expected then I guess it is an enhancement request. The use case being:

As a user, I want navigate to dependencytrack.company.com and access the dependency track UI without entering any username or password.

As a system admin, I want the dependency track UI open to anyone with access to the dependencytrack.company.com domain.

---

In our case, it may well be that we use something like OAUTH2Proxy infront of dependency track to enfore authentication with our SSO solution, but I don't think that is a concern of dependency track.

[samrocketman]

I have proposed:

• Frontend UI changes: https://github.com/DependencyTrack/frontend/pull/334
• Backend apiserver changes: https://github.com/DependencyTrack/dependency-track/pull/2169

[mbhegde-orcl]

I would like to see this feature (anonymous login) as well. The use case is putting dependency track behind an organization-internal OAuth2-proxy instance. I believe this is a widespread use case.

Since an authentication proxy is supposed to set some headers on incoming request, DependencyTrack can infer the user and groups through those headers. It can expose the configurations through properties, for example

dependencytrack.proxyAuth.usernameHeader=X-Username
dependencytrack.proxyAuth.groupsHeader=X-Groups

From the UI side, there would be a section called "Proxy Users", just like today there are Managed, LDAP and OIDC users.

@stevespringett in a related pull request, you mentioned that such a feature requires widespread changes in the API. Can you elaborate on that?

If it's something I can get done, I will be interested to contribute.