auth: allow cross-site session cookie for federation

[bbezak]

Set SESSION_COOKIE_SAMESITE to None whenever OpenStack federation and OIDC auth is enabled so the browser keeps the session during the WebSSO callback. Without this, the session cookie is stripped when Keystone runs on a different domain, and the flow ends with ?code=invalid_authentication_method.

Fixes #443

[bbezak]

tested locally, looks ok:

vanilla:

ubuntu@azimuth-wien-seed:~$ kubectl -n azimuth get secret azimuth-api     -o jsonpath='{.data.01-django\.yaml}' | base64 -d
SECRET_KEY: NOPE
DEBUG: false
CSRF_COOKIE_SECURE: true
SESSION_COOKIE_SECURE: true

with azimuth_chart_version: 0.16.2-dev.0.federation-different-domain.1

ubuntu@azimuth-wien-seed:~$ kubectl -n azimuth get secret azimuth-api     -o jsonpath='{.data.01-django\.yaml}' | base64 -d
SECRET_KEY: NOPE
DEBUG: false
CSRF_COOKIE_SECURE: true
SESSION_COOKIE_SAMESITE: None
SESSION_COOKIE_SECURE: true

[sd109]

As discussed elsewhere, I think this fix opens us up to CSRF exploits such as a malicious site being able to send state changing requests (e.g. DELETE to /api/tenancies/<id>/machines/<id>/ to delete a VM) which include the Django session cookie and therefore get executed as if they came from the logged in Azimuth user.

[bbezak]

As discussed elsewhere, I think this fix opens us up to CSRF exploits such as a malicious site being able to send state changing requests (e.g. DELETE to /api/tenancies/<id>/machines/<id>/ to delete a VM) which include the Django session cookie and therefore get executed as if they came from the logged in Azimuth user.

maybe we should store tokens server-side instead of sending it via cookie?

[sd109]

I've noticed that there's also a separate azimuth-csrftoken cookie which Django sets alongside the session cookie. It's possible that as long as this CSRF token cookie uses lax rather than none for the same site field then that's enough to protect us from the CSRF issue. I think I need to do some more careful reading of https://docs.djangoproject.com/en/5.2/ref/csrf/ to reassure myself of that though.

[JohnGarbutt]

I am a bit worried this opens us up to nasty CSRF attacks, and we have quite a lot of functional federation setups today with the current settings... I think because the all come from the same base site address.

Can we just make this easier to override to start with, till we work this one out in more details? (Clearly you totally need this for a scenario you are testing).

[JohnGarbutt]

I don't think we want this on by default, as this is working fine for all our current federation customers, and gives us better security I think.

For cases where you need to allow it, we should try and make this easier to change.

I think we assumed this was related to a problem when SSL wasn't turned on, but maybe the problem was deeper than we first thought, and was actually this one. Which makes sense.

[JohnGarbutt]

As discussed elsewhere, I think this fix opens us up to CSRF exploits such as a malicious site being able to send state changing requests (e.g. DELETE to /api/tenancies/<id>/machines/<id>/ to delete a VM) which include the Django session cookie and therefore get executed as if they came from the logged in Azimuth user.

maybe we should store tokens server-side instead of sending it via cookie?

I don't believe that changes things, the attack is still likely to work, I believe, as you still have to set a cookie to look up the details on the server side.

[JohnGarbutt]

Just to follow up here, is there not a config we can add to trust a specific extra domain, because I think in this case, its simply that federation is from a different domain, that we could allow explicitly?