User management is typically decoupled from resource management in Trellis. Yes, you can use basic auth and add users to a configuration file, but outside of local testing, I would never recommend using basic auth. The better mechanism follows an OAuth2/OpenID Connect model.
So, let's say you're using KeyCloak or Auth0 or Ping or Cognito (or any other OIDC-based auth system). Users will be managed in that external system, and that remote system will provide access tokens in the form of signed JWTs. That remote identity provider will also provide a URL where the public portion of its signing key(s) is located. These JWKS resources might look something like this:
https://trellisldp.auth0.com/.well-known/jwks.json
The Trellis server then needs to be configured to trust that identity provider. For this, I would highly recommend using the trellisldp/trellis-postgresql docker image, (it looks like the trellisldp/trellis docker container isn't set up for asymmetric remote key validation via configuration).
The relevant portion of the docker compose file would be something like this (it's a little different than the one you have been using because it uses a different (i.e. better) application platform):
image: trellisldp/trellis-postgresql:latest
environment:
QUARKUS_DATASOURCE_USERNAME: trellis
QUARKUS_DATASOURCE_PASSWORD: trellis
QUARKUS_DATASOURCE_JDBC_URL: jdbc:postgresql://db/trellis
# Add the JWKS location to the property below
Once that is set up, your clients would interact with the identity provider to generate access tokens -- you might use either an authorization code flow (if the client is browser based) or client credentials flow (for CLI applications). Those JWT access tokens are passed to the Trellis server for authentication using the Authorization header. The WebID is formed by combining the issuer claim with the subject claim. For example, if the issuer is
https://identity.example/ and the subject is acoburn, then the webid would be
https://identity.example/acoburn.
Hope that helps,
Aaron