feat: add basic auth to Zeebe deployments

[philippfromme]

• adds basic auth to self-managed deployments
• aligns naming of endpoint types and authentication types across codebase

Closes #4160

[nikku]

Looks good. How did you E2E-test your solution?

[barmac]

The credentials should be redacted from the log:

ERROR app:zeebe-api connection check failed {
  parameters: {
    endpoint: {
      type: 'selfHosted',
      authType: 'basic',
      url: 'http://localhost:8000',
      basicAuthUsername: 'abc',
      basicAuthPassword: 'def'
    }
  }
}

[philippfromme]

@nikku No success testing this end-to-end. I'm trying to get help from the Zeebe team. Otherwise I'd need your help.

[philippfromme]

@barmac Done: b346b79

[nikku]

I was able to end-to-end test this using a standard reverse proxy setup, based off our zeebe-connection-test project, basic-auth branch.

Topology (test setup)

Camunda Modeler -> [NGINX; enforces basic auth] -> Zeebe

Test it yourself

You can use the following script to test it yourself ™️:

# Clone repository
git clone git@github.com:camunda/zeebe-connection-test.git
cd zeebe-connection-test
git checkout -b basic-auth

Proceed with the run instructions to spin up Zeebe.

Then to test with the Camunda Modeler specify self-managed, http://sub.example.com, basic auth and pass demo:demo as credentials.

---

Test results

• Initially when no credentials are provided we pass undefined for both basic auth username and password; I suggest we rather pass '' (an empty string). Otherwise zeebe-node will assume no basic auth is set

• When testing for errors we do not properly handle authentication failures. What I see is the standard "Cannot connect to Zeebe cluster" error, but no indication that this may be due to wrong or missing credentials.

  

Besides these two things it works; I can deploy successfully.

[nikku]

To be followed-up, cf. #4269 (comment).

[philippfromme]

I'm not sure how to deal with the errors. After setting up a reverse proxy with basic auth the error I get when using the wrong credentials is

Error: 13 INTERNAL: Received RST_STREAM with code 0\n at callErrorFromStatus (C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\call.js:31:19)\n at Object.onReceiveStatus (C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\client.js:192:76)\n at C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\call-interface.js:78:35\n at Object.onReceiveStatus (C:\workspace\camunda\camunda-modeler\node_modules\zeebe-node\dist\lib\GrpcClient.js:97:36)\n at InterceptingListenerImpl.onReceiveStatus (C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\call-interface.js:73:23)\n at Object.onReceiveStatus (C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\client-interceptors.js:360:141)\n at Object.onReceiveStatus (C:\workspace\camunda\camunda-modeler\node_modules\@grpc\grpc-js\build\src\client-interceptors.js:323:181)\n at C:\workspace\camunda\camunda-modeler\node_modules… …

which is just a GRPC error but doesn't provide any hint that this might be related to wrong credentials.

I could just map code === 13 && authType === 'basic' to an unauthorized error but I suspect that this error can also occur unrelated to wrong credentials. 🤔

[philippfromme]

@nikku @barmac We could decide to fix the error handling as a follow-up.

[nikku]

Agreed that it makes sense to maybe improve the error handling as a follow-up.