Updating Crowd 4.3.8 to 6.3

XenGi

I'm trying to upgrade a crowd installation from 4.3.8 to 6.3.

Crowd runs in Kubernetes with a PostgreSQL DB. I created a XML backup from the old version and then as a test started a fresh crowd 6.3 container with my local Docker. During the setup wizard I imported the XML backup and everything worked fine.

When I tied the same procedure in Kubernetes things didn't work out. Here I have an nginx proxy in front of crowd which uses Basic Auth for additional security. I set the following vars for the crowd deployment:

• ATL_PROXY_NAME="crowd.myproxy.net"
• ATL_PROXY_PORT="443"
• ATL_TOMCAT_SCHEME="https"
• ATL_TOMCAT_SECURE="false"

I'm not entirely sure what the ATL_TOMCAT_SECURE setting does. If I leaf these settings out I can accessmy crowd instance via the service domain crowd.my-namespace.svc.cluster.local but when I try to access it via the proxy crowd.myproxy.net the login page loads forever.

When I add the mentioned env vars to the deployment using the service URL results in the following error in the logs and me not being able to login:

│ crowd 2025-05-07 10:01:58,438 http-nio-8095-exec-23 WARN [v2.security.xsrf.XsrfResourceFilter] Additional XSRF checks failed for request: https://crowd.myproxy.net/crowd/rest/tsv/1.0/authenticate , origin: http://crowd.my-namespace.svc.cluster.local , referrer: http://crowd.my-namespace.svc.cluster.local/crowd/console/login.action , credentials in request: true , allowed via CORS: false

The login page via the proxy URL also loads forever in this setup.

It hangs on a GET request to: https://crowd.myproxy.net/crowd/rest/authconfig/1.0/login-options

I'm out of ideas. I tried setting the base URL to https://crowd.myproxy.net/crowd/ and http://crowd.my-namespace.svc.cluster.local but the behavior didn't change.

Changing ATL_TOMCAT_SECURE to true has no effect.

What am I doing wrong here?

XenGi

Found the solution. But first let's describe the problem better.

When you run Crowd behind a nginx proxy that adds basic auth, the Authorization header also gets forwarded to Crowd by default. When crowd then tries to get login methods via "/crowd/rest/authconfig/1.0/login-options" it uses this header to reach it's API and gets a 401 back for that auth. No idea why this endpoint checks this header.

When removing the Authorization header after the proxy successfully authenticated the user via basic auth everything seems to be fine. Only setup the proxy settings as described in the docs. So I configure my authenticating proxy like this:

server {
  listen 80;
  access_log off;
  location / {
    auth_basic_user_file /etc/nginx/htpasswd;
    auth_basic "Crowd Auth";
    proxy_pass crowd.my-namespace.svc.cluster.local;
    proxy_set_header Host $host;
    proxy_http_version 1.1;
    proxy_set_header X-Real-IP $remote_addr;
    # $scheme is http at this proxy but needs to be set to https from the ingress proxy
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # If "Authentication" is set, Crowd gives XSFR/CORS errors
    proxy_set_header Authorization "";
  }
}

You probably don't need all of the headers but I don't have any energy left to figure out a minimal setup.
The container setup gets envs like this:

- name: ATL_PROXY_NAME
  value: "crowd.mydomain.net"
- name: ATL_PROXY_PORT
  value: "443"
- name: ATL_TOMCAT_SCHEME
  value: "https"
- name: ATL_TOMCAT_SECURE
  value: "true"

 Any config for the base url, trusted proxies etc inside crowd doesn't seem to matter.

So feel free to play around more and figure the rest out. I just hope I never have to touch Atlassian software again.