We want to support a flow for SSO-enabled Enterprise customers who have
agreed off-platform that none of their learners will opt-in to marketing emails
or sharing research data. This change proposes to do so by
adding an optional field that, when enabled, disables the presence of
the two checkboxes on this registration form and sets their values to false.
ENT-11401
Removes temporary rollout toggle ENABLE_SAML_CONFIG_SIGNAL_HANDLERS. The
toggle was used to rollout a fix, and now the fix that uses the signal handlers is
enabled by default.
The only follow-up needed by anyone is to no longer set this toggle, which will no
longer do anything.
- Removes custom attributes for report. Uses report output only.
- Adds a count for disabled SAML configs.
- Displays disabled status of provider.
- Slug mismatch now informational only (rather than warning)
* Cleans up unit tests.
The SAML management command has been refactored from
an auto-update tool to a comprehensive report-only audit system.
The changes introduce a new --run-checks option that provides
detailed reporting on SAML configuration issues without making
any automatic changes.
Add a json auth endpoint where previously there was only an HTML redirect version. This will make it easier to work with MFEs.
---------
Co-authored-by: Feanil Patel <feanil@axim.org>
Introduces temporary rollout toggle ENABLE_SAML_CONFIG_SIGNAL_HANDLERS
which controls whether SAML configuration signal handlers are active.
When enabled (True), signal handlers will automatically update SAMLProviderConfig
references when the associated SAMLConfiguration is updated.
When disabled (False), SAMLProviderConfigs point to outdated SAMLConfiguration.
Warning: Disabling this toggle may result in SAMLProviderConfig instances
pointing to outdated SAMLConfiguration records.
Use the management command 'saml --fix-references' to fix outdated references.
Some models in third_party_auth used settings.SITE_ID as a field
default, which caused Django to say migrations were out of sync whenever
settings.SITE_ID happened to be anything other than 1 for any developer:
Your models in app(s): 'third_party_auth' have changes that are not
yet reflected in a migration, and so won't be applied. Run
'manage.py makemigrations' to make new migrations, and then re-run
'manage.py migrate' to apply them.
This could easily happen if a developer is testing out site
configuration or site-specific theming and ends up with a SITE_ID other
than 1.
The fix, inspired by a StackOverflow answer [1], is to simply create
a wrapper function for the dynamic default value. The wrapper function,
rather than the current value of SITE_ID, will be serialized to the
migraiton file.
This commit includes a migration file, but from a database perspective,
the migration is a no-op.
[1] https://stackoverflow.com/a/12654998
* chore: update API endpoints to support default JWT auth
The default DRF Auth classes were recently updated to allow for both JWT and Session auth by default. Any endpoint that overrides the AUTHENTICATION_CLASSES but has just session, just JWT or just both of those should be updated to remove the override.
Details in https://github.com/openedx/edx-platform/issues/33662
Allows admins to configure same oauth backend for multiple sites.
This change includes site_id in KEY_FIELDS for oauth configuration
provider allowing a backend configuration for each site.
We would like to catch an error in SAML auth so that
we can handle it better in our observability. This
catches the original generic error and raises it as a more
specific one.
https://github.com/edx/edx-arch-experiments/issues/154
