WebApps Authorization Issues

Camunda 7 Topics Discussion & Questions
,
1

I am having WebApps Authorization problems with one of our Camunda deployments.

In one, everything works fine - I can navigate to /app/admin/default/#/login, provide my admin credentials, and the Admin page (/app/admin/default/#/) comes up fine.

In the other, after providing my credentials, I see the Admin page for a quick second, then it returns to the login screen. Looking a Chrome’s DevTools, I see the following XHR calls:

POST /api/admin/auth/user/default/login/admin

Returns 200 with body {userId: “CamundaAdminStg”, authorizedApps: [“admin”, “tasklist”, “welcome”, “cockpit”]}.

GET /api/engine/engine/default/user/CamundaAdminStg/profile

Returns 401 with body {“timestamp”:“2018-08-23T19:24:34.415+0000”,“status”:401,“error”:“Unauthorized”,“message”:“No message available”,“path”:"/api/engine/engine/default/user/CamundaAdminStg/profile"}

OPTIONS /api/engine/engine/default/user/

Returns 200 with headers:
x-authorized-apps: admin,tasklist,welcome,cockpit
x-authorized-engine: default
x-authorized-user: CamundaAdminStg

OPTIONS /api/engine/engine/default/group/

Returns 401

…

I am at a loss why the one deployment works fine, but this one does not.

I’m not sure if its related, but most all responses from the webserver with problems change the JSESSIONID cookie with the set-cookie response header. On the webserver where the WebApps work fine, the JSESSIONID is not changed.

2

Ok, we have determined that the problem is caused by us not maintaining session affinity behind our ALB’s. The deployment that has no issues has a single instance, while the deployments that are failing have multiple instances behind the ALB.
However, we would rather not introduce session affinity, because our servers are stateless (and scaleable) at the moment.
Is there anyway to configure the Camunda Webapps to work without session affinity?

3

Dear knotthere,

I’m going to install the full version 7.10 on Wildfly and stepped into a nearly similar problem: Even the Admit Application lost it’s session while a XHR POST (add a new user) request because it uses another JSESSIONID as the foregoing requests used to display the UI.

May you or anybody other give me a hint what’s wrong with the setup? I tested the standalone version with the embedded bpm engine before and using this, there was no such problem.

with greetings
Guido

4

Just figured out that my issue is related to the (new?) CSRF Prevention filter and its XSFR-TOKENs. The issue vanishes if I disable it in the web.xml .

I’ll open a new Issue about that.

6

It has been several years. Did you find any solution?

7

@knotthere @hanscrg
Team

Has anyone found some solution? How to get this working.

8