Default auth for Ditto

[neottil]

I tried the installation with helm from docker hub with the command suggested in the readme "helm install -n ditto my-ditto oci://registry-1.docker.io/eclipse/ditto --version 3.3.3 --wait".
Trying to run a curl I get a 401 response "{"status":401, "error": "gateway:authentication.failed", "message": "Unauthorized.", "description": "Check if your credentials were correct."}" I tried editing the secret my-ditto-nginx-config-nginx-htpasswd by entering (in base64 format) the credentials created with the command "htpasswd -c tmp/nginx/.htpasswd ditto".
Restarting the nginx pod, the /etc/nginx/nginx.htpasswd file contains the expected string, but the curl still returns 401.

I can't figure out what is not working and how I can properly configure the user for Ditto access.

[thjaeckle]

@neottil Oh, I think the default of jwtOnly changed from false to true now - which will by default disable the nginx based authentication.

I will address this in a fix - as I also assume that for "simple" scenarios the Chart should support nginx based authentication by default.

In the meantime: Could you try installing the Helm chart with --set global.jwtOnly=false and see if it then works?

[thjaeckle]

Default is changed to jwtOnly: true in #1686

[neottil]

Thank you for the quick response.
I tried as you suggested and then editing the secret to add the credentials, but it doesn't seem to work.

I attach result of htpasswd file from nginx pod. (ditto:ditto from htpasswd cmd)
ditto:$apr1$BCZAM1Tk$PSRc0rtZPWxP3esp6K3AS1

Also I attach result of nginx.conf file.

    location /api {
      include nginx-cors.conf;


      auth_basic                    $authentication;
      auth_basic_user_file          nginx.htpasswd;
      proxy_set_header              X-Forwarded-User          $remote_user;
      proxy_set_header              x-ditto-pre-authenticated $nginx_auth_user;

      proxy_pass                    http://my-ditto-gateway;
      proxy_http_version            1.1;
      proxy_set_header              Host                      $http_host;
      proxy_set_header              X-Real-IP                 $remote_addr;
      proxy_set_header              X-Forwarded-For           $proxy_add_x_forwarded_for;

      proxy_set_header Connection  '';
      chunked_transfer_encoding    off;
      proxy_buffering              off;
      proxy_cache                  off;
    }

this is the curl results:
root@my-ditto-nginx-64d75f7f45-tv5lf:/# curl -u ditto:ditto http://localhost:8080/api/2/things
{"status":401,"error":"gateway:authentication.failed","message":"Unauthorized.","description":"Check if your credentials were correct."}

The authentication on nginx seems to be done, but the gateway does not recognize it. Perhaps there is something wrong with the nginx proxy configurations?

I have also tried setting the hashedBasicAuthUsers value with --set global.hashedBasicAuthUsers="{ditto:$apr1$xLvUY4C.$eYEe57EtKAzmHkJ.U3Jrb0}" (ditto:ditto), but I'm afraid that's not the correct way to set the value since I find a mismatched value in the secret.

[mladBlum]

Hello,

I am glad that i have found your discussion. I have the same problem and I am pretty sure I found the issue today.

tl;dr:

The quick solution is to set ingress.api.paths /api to nginx.

ingress:
  api:
    # paths configures ingress paths
    paths:
      - path: /api
        backendSuffix: **nginx**

The long answer because this is probably an issue with the helm-chart:

Just for context, the environment in which I use the Eclipse Ditto chart is an Azure Kubernetes Services with a working nginx-ingress-controller and a cert-manager.

To keep things simple to describe I am using the local-values.yaml with mongodb.enabled: true.
The intention is to create an ingress so that all the endpoints of ditto are available with basic auth under a certain domain like https://ditto.my-domain.com/... .
To achieve that i added the following lines to the values.yaml:

ingress:
  enabled: true
  className: nginx
  host: ditto.my-domain.com
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
  tls:
    - secretName: ditto.my-domain.com
      hosts: 
        - ditto.my-domain.com

After this change, i am able to get the Eclipse Ditto page with health and statistics under https://ditto.my-domain.com/. After setting a devOpsPassword in values.yaml I am also able to call https://ditto.my-domain.com/devops/config with the correct credentials.
But when I try to call any https://ditto.my-domain.com/api/* endpoint with the ditto user i just get a HTTP 401 Unauthorized response.

It gets really interesting in the log of the eclipse-ditto-gateway:

{"@timestamp":"2023-07-11T16:53:48.342+02:00","@version":"1","message":"Unexpected authentication failure for URI <http://ditto.my-domain.com/api/2/search/things>: <IllegalStateException: No applicable authentication provider was found!>","logger_name":"org.eclipse.ditto.gateway.service.endpoints.directives.auth.GatewayAuthenticationDirective","thread_name":"ditto-cluster-akka.actor.default-dispatcher-12","level":"WARN","level_value":30000,"stack_trace":"java.lang.IllegalStateException: No applicable authentication provider was found!\n\tat org.eclipse.ditto.gateway.service.security.authentication.AuthenticationChain$AuthResultAccumulator.asFailure(AuthenticationChain.java:202)\n\tat java.base/java.util.Objects.requireNonNullElseGet(Objects.java:310)\n\tat org.eclipse.ditto.gateway.service.security.authentication.AuthenticationChain$AuthResultAccumulator.getResult(AuthenticationChain.java:218)\n\t at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)\n\tat java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)\n\tat akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49)\n\tat kamon.instrumentation.executor.ExecutorInstrumentation$InstrumentedThreadPool$TimingRunnable.run(ExecutorInstrumentation.scala:466)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)\n\tat java.base/java.lang.Thread.run(Thread.java:833)\n","correlation-id":"b3cee012-bd94-4be0-bfac-d7b3a915ac5b"}

It seems that the gateway is not able to authenticate the request?! After this I tried to follow the route of the request and i stumbled over this default configuration in values.yaml:

ingress:
  api:
    # paths configures ingress paths
    paths:
      - path: /api
        backendSuffix: gateway
      - path: /devops
        backendSuffix: gateway
      - path: /status
        backendSuffix: gateway
      - path: /stats
        backendSuffix: gateway
      - path: /overall
        backendSuffix: gateway
      - path: /health
        backendSuffix: gateway

If my understanding is correct, then the ingress routes the /api endpoint directly to the gateway. Ditto's Nginx is omitted although it should do the basic auth stuff.
I am not a jwt or oAuth expert but in the case of basic auth I think the configuration should look like this:

ingress:
  api:
    # paths configures ingress paths
    paths:
      - path: /api
        backendSuffix: nginx

At this point the question is if these defaults in the chart are correct. Because everyone who enables basic auth and a ingress will face a HTTP 401 Unauthorized.

[thjaeckle]

@mladBlum that is a very good catch indeed 👍
From my understanding you have identified the problem.

For me, the nginx-based authentication is kind of a "hack" to get things running quickly with Ditto, without e.g. requiring an OAuth2 provider. So e.g. for a local setup / demo / private installation.
However for a real productive use (where also an Ingress-Controller is an important part), I don't see that this nginx-based authentication is a "good thing" to rely on.

If you need to have the nginx-based authentication for productive cases, I would personally try to add this to the Ingress nginx controller setup instead of using the additional nginx of Ditto - because you would have another additional network "hops" for all /api requests.

The Helm chart could be enhanced to support this corner case:

• activated Ingress (ingress.enabled: true)
• using nginx-based authentication (global.jwtOnly: false)
• using nginx of Ditto (nginx.enabled: true)

And in this constellation replace backendSuffix of /api ingress resource with nginx instead of gateway.
Or the Helm chart could solve that in its own Ingress controller (activated with ingress.controller.enabled = true).

Either way, contributions to the chart are welcome, I do not have a use for this scenario.

[neottil]

@thjaeckle, @mladBlum Thank you for the support. I too think that in production it is not a best practice to use basic auth, but for a demo or test environment I think it is important to have a ready installation in a few moments and without making major changes. I will try the proposed solution in the coming days. II will try to configure helm files to make this setting more automatic for contribution.

[neottil]

@thjaeckle I tried the suggested configuration:

• activated Ingress (ingress.enabled: true)
• using nginx-based authentication (global.jwtOnly: false)
• using nginx of Ditto (nginx.enabled: true)
• replace backendSuffix of /api ingress resource with nginx instead of gateway
  Unfortunately, it does not work. I get the same error from the gateway.
  However, it is not clear to me why I should enable ingress. If I leave it disabled and configure basic auth the curl I make queries nginx which authenticates me and forwards the call to the gateway adding the header "x-ditto-pre-authenticated". I can't figure out what the error is for the gateway. Why does it say it can't find an auth provider?
  For me it remains critical to provide a ready-to-go product as a demo, don't you think? Obviously in a final installation everyone will choose the cnfigurations that suit them best.

[neottil]

@thjaeckle Even setting the parameter ingress.controller.enabled = true the situation does not change.

[mladBlum]

With Ditto 3.3.6 the whole solution here does not work anymore.
At the moment I'm very curious if anyone can successfully host ditto 3.3.6 with basic-auth in a Kubernetes cluster.
I am pretty sure this feature has something to do with my problems: #1702

As soon as I understand the problem a little more clearly I will report back here.