SAML IdP "hinted links" not working in Lilac

Hi all! We are facing a SAML issue with Lilac. After upgrading from koa to lilac, the SAML hinted sign in links are not working anymore, more precisely, the redirection after login does not work. It appears that the “next” param gets dropped and learners will land on /dashboard always instead of being taken to the correct page. It also appears that the issue is only with SAML (okta).

When SAML provider is in debug mode, we can see that the “next” parameter is there in the request but for some reason None on the response:

2021-12-15 08:15:34,123 INFO 22107 [common.djangoapps.third_party_auth.saml] [user None] [ip 127.0.0.1] saml.py:178 - SAML login request for IdP okta. Data: <QueryDict: {'auth_entry': ['login'], 'next': ['/courses/<course-id>/course/?tpa_hint=saml-okta'], 'idp': ['okta']}>. Next url /courses/<course-id>/course/?tpa_hint=saml-okta. XML is:
2021-12-15 08:15:34,696 INFO 21978 [common.djangoapps.third_party_auth.saml] [user None] [ip 127.0.0.1] saml.py:178 - SAML login response for IdP okta. Data: <QueryDict: {'SAMLResponse': ['<redacted>'], 'RelayState': ['okta']}>. Next url None. XML is:

Has anyone else run into this? What changed between koa and lilac that could affect the SAML hinted links?

What is different between our koa and lilac platforms is that for lilac we enabled the Account MFE, could that be somehow related? Before that we were not using any MFE’s, I am wondering about the following settings:

EDXAPP_CORS_ORIGIN_WHITELIST:
  - "{{ EDXAPP_CMS_BASE }}"
  - "{{ MFE_BASE }}"
EDXAPP_CSRF_TRUSTED_ORIGINS:
  - "{{ MFE_BASE }}"
EDXAPP_ENABLE_CORS_HEADERS: true
EDXAPP_ENABLE_CROSS_DOMAIN_CSRF_COOKIE: true
EDXAPP_CROSS_DOMAIN_CSRF_COOKIE_DOMAIN:
EDXAPP_CROSS_DOMAIN_CSRF_COOKIE_NAME:

Any help is much appreciated, thanks!

1 Like

I haven’t looked closely but my gut sense is that one of these locations is relevant:

I work with @mrtmm on this issue, and I hope @jill doesn’t mind being tagged here as I’m hopeful she might have ideas on this issue, being the author of this PR: :slight_smile:

If we’re able to see the next URLs in the memcached entries corresponding to a session, is it safe to assume that the SAML TPA pipeline should be able to populate the next_url variable from that cached session entry, once it processes the successful SAML response? In other words, if it does not, is it OK to assume that something broke between Koa and Lilac, and that this is more likely to be a bug than a configuration issue?

We can scratch that, it shouldn’t be related. I’ve spun up an instance with everything MFE disabled and still was facing the same issue…

@Tim_McCormack thanks for the suggestion! I’ve been looking at those bits of code quite a bit but yes, we should be seeing something in the logs if the issue was coming from there. Also, I don’t see any logic changes there between koa and lilac :confused:

I think next_url is lost because of the session is lost when user lands back on LMS after authentication. The reason of session lost could be DCS_SESSION_COOKIE_SAMESITE setting. can you make sure

DCS_SESSION_COOKIE_SAMESITE = “None”
when
SESSION_COOKIE_SECURE = True

OR
DCS_SESSION_COOKIE_SAMESITE = “Lax”
when
SESSION_COOKIE_SECURE = False

1 Like

We set:

DCS_SESSION_COOKIE_SAMESITE: Lax
SESSION_COOKIE_SECURE: true

But on that note, what does this mean exactly?

DCS_SESSION_COOKIE_SAMESITE_FORCE_ALL: true

Could this somehow break the use of next=?

@fghaas could you please try setting

DCS_SESSION_COOKIE_SAMESITE="None"

This PR and discussion has some context on this setting and why next_url is dropped.

Right, that worked for us, thank you!

(Also, thanks for the edit on the earlier suggestion; that makes it clearer. :slight_smile: )

I’d like to point out that in testing this change, we ran into the issue that it is apparently un-testable in Devstack.

In Devstack, we had this in /edx/etc/lms.yml:

# grep DCS_SESSION_COOKIE_SAMESITE /edx/etc/lms.yml 
DCS_SESSION_COOKIE_SAMESITE: None
DCS_SESSION_COOKIE_SAMESITE_FORCE_ALL: true

But checking with manage.py lms shell showed:

# ./manage.py lms shell
Python 3.8.10 (default, Jun  2 2021, 10:49:15) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.conf import settings
>>> print(settings.DCS_SESSION_COOKIE_SAMESITE)
Lax

(And yes, we checked if quoting 'None' made any difference; it did not. That setting apparently just can’t be overridden from lms.yml in Devstack.)

It looks as though that is due to this commit:

The rationale behind that change isn’t quite clear to me. I just wanted to mention it here in case others run into the same issue, and fruitlessly attempt to make that configuration change in Devstack.

Thanks again for the help!

1 Like

Thanks @Zia_Fazal! :slight_smile:

Wow, great catch, Zia!