Desktop Modeler fails to deploy to self-managed Cluster with Identity (415, Unsupported Media Type)

[rob2universe]

Describe the bug

After setting the deployment parameters for self-managed and oAuth, the deployment fails. The Modeler log shows:
01:39:00,341 WARN [org.keycloak.events] (default task-11) type=LOGIN_ERROR,

2022-09-23T05:46:55.716Z ERROR app:zeebe-api Failed to connect with config (secrets omitted): {
endpoint: {
type: 'oauth',
url: '127.0.0.1:26500',
clientId: 'java',
oauthURL: 'http://127.0.0.1:18080/auth/realms/camunda-platform/protocol/openid-connect/token'
}
} GotError [HTTPError]: Response code 415 (Unsupported Media Type)
at EventEmitter. (C:\tools\camunda-modeler\resources\app.asar\node_modules\got\source\as-promise.js:74:19)
at process.processTicksAndRejections (node:internal/process/task_queues:96:5) {
host: '127.0.0.1:18080',
hostname: '127.0.0.1',
method: 'POST',
path: '/auth/realms/camunda-platform/protocol/openid-connect/token',
socketPath: undefined,
protocol: 'http:',
url: 'http://127.0.0.1:18080/auth/realms/camunda-platform/protocol/openid-connect/token',
gotOptions: {
path: '/auth/realms/camunda-platform/protocol/openid-connect/token',
protocol: 'http:',
slashes: true,
auth: null,
host: '127.0.0.1:18080',
port: '18080',
hostname: '127.0.0.1',
hash: null,
search: null,
query: null,
pathname: '/auth/realms/camunda-platform/protocol/openid-connect/token',
href: 'http://127.0.0.1:18080/auth/realms/camunda-platform/protocol/openid-connect/token',
retry: {
retries: [Function (anonymous)],
methods: [Set],
statusCodes: [Set],
errorCodes: [Set]
},
headers: {
'user-agent': 'zeebe-client-nodejs/2.4.0',
'content-type': 'application/json',
'accept-encoding': 'gzip, deflate',
'content-length': 128
},
hooks: {
beforeRequest: [],
beforeRedirect: [],
beforeRetry: [],
afterResponse: [],
beforeError: [],
init: []
},
decompress: true,
throwHttpErrors: true,
followRedirect: true,
stream: false,
form: false,
json: false,
cache: false,
useElectronNet: false,
body: '{"audience":"127.0.0.1","client_id":"java","client_secret":"5N1lW0ykk7UgVyaL1g1oV5a72Yigdz5V","grant_type":"client_credentials"}',
method: 'POST'
},
statusCode: 415,
statusMessage: 'Unsupported Media Type',
headers: {
'x-xss-protection': '1; mode=block',
'x-frame-options': 'SAMEORIGIN',
'referrer-policy': 'no-referrer',
date: 'Fri, 23 Sep 2022 05:46:55 GMT',
connection: 'close',
'strict-transport-security': 'max-age=31536000; includeSubDomains',
'x-content-type-options': 'nosniff',
'content-type': 'application/json',
'content-length': '55'
},
body: '{"error":"RESTEASY003065: Cannot consume content type"}'
}

It seems worth noting that the client id her does not reflect the the Id entered in the modeler ("java") and the auth_type may need to be "client credentials" instead of code.

Authentication from curl or Postman works, e.g:

curl --location --request POST 'http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=java' --data-urlencode 'client_secret=xyz' --data-urlencode 'grant_type=client_credentials'
{"access_token":"shortened-it_works","expires_in":300,"refresh_expires_in":0,"token_type":"Bearer","not-before-policy":0,"scope":"profile email"}

Steps to reproduce

1. Try to deploy a process model from Desktop modeler to a self-managed Camunda 8 with Identity enabled
2. notice error message can check modeler log

Expected behavior

Deployment succeeds if parameters are set correctly.
Meaningful connection or authentication error is shown if parameters are incorrect (not "unknown error")

Environment

• win 11
• Camunda Modeler Version: 5.3.0
• Execution Platform: https://github.com/rob2universe/camunda-8-helm-profiles/tree/dev-identity/dev-identity

Additional context

No response

---

Related to SUPPORT-14704

[daniel-ewing]

I tried this running locally in Docker with the default docker-compose.yaml. For the OAuth URL, I tried:

• http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token
• http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/auth

For the Cluster endpoint, I tried:

• 0.0.0.0:26500
• 127.0.0.1:26500
• localhost:26500

All combinations produced the same error given above. Modeler shows this error message:

[daniel-ewing]

Hi @barmac, I'm not sure this is related to SSL. I did not specifically configure any certificates to set up SSL in my C8-SM instance. I do not think C8-SM configures SSL by default. Further to that, I also cannot deploy a model to the same C8-SM instance using zbctl. Am I doing something wrong or is it simply impossible to deploy to a C8-SM instance running with Identity (with or without SSL), unless you use a Java application?

[MaxTru]

Also see https://jira.camunda.com/browse/SUPPORT-14704

[barmac]

Not sure if we can fix the issue in the Modeler if the problem lies within the client (either zbctl, or zeebe-node which we use in the app). Thanks for the insights so far. I will try to reproduce this problem and will get back with the findings.

[CatalinaMoisuc]

Not sure if we can fix the issue in the Modeler if the problem lies within the client (either zbctl, or zeebe-node which we use in the app). Thanks for the insights so far. I will try to reproduce this problem and will get back with the findings.

Thank you @barmac would be great if you manage to reproduce it and pinpoint the problem, that will enable us to delegate the responsibility for fixing this issue to the right people.

[barmac]

OK I am actively looking into this. I will get back to you with the results.

[barmac]

So far I was able to setup a k8s cluster with Identity enabled. However, with port-forwarding I can deploy directly to Zeebe without any oauth configuration 🐒 . I cannot connect to Zeebe due to error:

ERROR app:zeebe-api Failed to connect with config (secrets omitted): {
  endpoint: {
    type: 'oauth',
    url: 'http://localhost:26500',
    clientId: 'java',
    oauthURL: 'http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token'
  }
} Error: 14 UNAVAILABLE: No connection established

I suspect that this is because we enforce SSL for oAuth connection, but would need to investigate this yet.

[barmac]

I was able to reproduce the exact error as shared by @rob2universe in the issue (415 Unsupported Media Type). This was on v5.3.0. When I switched to v5.4.1 (current), with the same credentials the client reported 401 Unauthorized with error '{"error":"unauthorized_client","error_description":"Invalid client secret"}', although I was able to retrieve the token using the exactly same secret.

[barmac]

I checked the log thoroughly and it seems that app used an old secret even when I changed the input value, so that would explain the 401 error.

[barmac]

It may also be that oAuth is broken in v5.4.1 based on the changelog of the zeebe client we use: https://github.com/camunda-community-hub/zeebe-client-node-js/blob/master/CHANGELOG.md#fixes

[barmac]

@rob2universe Are you able to reproduce this with Camunda Modeler v5.4.1?

[barmac]

I built a minimal example for zeebe-node@8.1.0 which is independent from internals of Camunda Modeler. I confirmed that for my local cluster:

1. I can connect with no auth configured.
2. I cannot connect when using oAuth configuration (14 UNAVAILABLE: No connection established).

The minimal example

const { ZBClient } = require('zeebe-node');

main();

async function main() {
  const zbc = new ZBClient({
    onConnectionError(error) {
      console.error('Connection error', error);
    },
    onReady(event) {
      console.log('Connected to Zeebe', event);
    }
  });

  const topology = await zbc.topology();

  console.log(topology);
}

I will check if the problem persists with the latest version of zeebe-node.

[barmac]

With zeebe-node@8.1.2 (latest), it still fails to connect. Same for zeebe-node@8.0.0.

[barmac]

OK now I was able to reproduce 415. Some research indicates it's a problem with the request sent to Keycloak: keycloak/keycloak#11971. Notice the error part: RESTEASY003065

[barmac]

In Camunda Modeler 5.4.1, zeebe-node enforces TLS if oAuth is configured. This makes sense from the production point of view (prevents sending token in plain text), but makes it impossible to deploy to a local development cluster. The solution to the problem which I verified is to explicitly set useTLS option on the Zeebe client based on the protocol of provided cluster URL.

[barmac]

Closed via #3242

[nikku]

@barmac I guess it does not hurt if we cut a patch for it?

[nikku]

Shall I do this?

[barmac]

Feel free to do it!

[nikku]

Was not able to follow-up, unfortunately.

[barmac]

The fix was released with v5.4.2