Summary

If the portal lives at https://portal.example.com and Keystone’s WebSSO endpoint sends users back from https://keystone.example.net:5000, the POST to /auth/federated/complete/ arrives without the Django session
cookie. Azimuth then can’t recover the stored option and redirects with code=invalid_authentication_method.

Steps to reproduce

1. Deploy Azimuth with OpenStack federation where portal and Keystone domains differ (e.g. portal.example.com vs keystone.example.net).
2. Launch the federated login.
3. After the WebSSO redirect, the portal returns to the login page with invalid_authentication_method.

Expected

The session cookie survives the callback and the user reaches /tenancies.

Actual

Session cookie is dropped (browser blocks SameSite=Lax on a cross-site POST), so the callback fails.

Workaround

Set SESSION_COOKIE_SAMESITE: None in the azimuth-api Django settings secret and restart the deployment.

Proposed fix

Have the chart emit SESSION_COOKIE_SAMESITE: None automatically whenever authentication.type == "openstack" with federated.enabled: true (and optionally for type == "oidc"). For example:

https://github.com/azimuth-cloud/azimuth/blob/8b1eb6f069ba0bd459e73b748ee8ca4829c3d844/chart/files/api/settings/01-django.yaml

  {{- if and (eq .Values.authentication.type "openstack") (.Values.authentication.openstack.federated.enabled) }}
  SESSION_COOKIE_SAMESITE: None
  {{- end }}

That keeps the default Lax otherwise, but handles cross-site WebSSO safely out of the box.