Scaling Camunda versus Security problem

Camunda 7 Topics Discussion & Questions
,
1

Good day,

I’m tripping over such a problem - the moment I scale Spring Boot Camunda 7 app to 2+, I can no longer auth through the web. After a second of thinking, I’m getting a Wrong credentials, locked user or missing access rights to application.

I did go with that approach, and it did seem to work, but apart from me not meddling with Spring Security for the last… 7 years (Spring Boot was still something new in those days), with a dash of me still learning Camunda, I’m getting the impression that disabling such a crucial part of the production app… is NOT a good thing.

I did go through the forum and found a few possible things to tweak, but none of them seem to touch the subject of “the moment I scale the app”.

My security config is basic:

    @Bean
    public FilterRegistrationBean processEngineAuthenticationFilter() {
        FilterRegistrationBean registration = new FilterRegistrationBean();
        registration.setName("camunda-auth");
        registration.setFilter(new ProcessEngineAuthenticationFilter());
        registration.addInitParameter("authentication-provider", HttpBasicAuthenticationProvider.class.getName());
        registration.addUrlPatterns("/*");
        return registration;
    }

Found this one right here Configure Authentication | docs.camunda.org

But I’m still facing this problem.

Any ideas?

2

Hi,

Multiple instances of the Camunda webapps don’t share their sessions, so the user will log in to one of them but subsequent requests to the others will fail.

Solutions:

  • Use sticky sessions in your request routing, so that requests for the same session always go the same instance. This is the recommended approach.
  • Configure persistent sessions in Spring Boot. Not sure how well this works, maybe there is something on it in the forum.

Cheers,
Thorben

1 Like
3

I’m having mixed thoughts that this is handled by Spring Boot and not by Camunda
image

I’ve tried logging debug both camunda and spring boot, but I still can’t find who is giving the call.

Sticky session is “not desirable”, and google makes me believe that persistent session has been as default for some time now. I did try some props, but that didn’t seem to give any effect