[DEPR]: SAMLProviderConfig reference to outdated SAMLConfiguration

[robrap]

RFC Start Date

2025-06-23

Target Plan Accepted Date

2025-07-07

Target Transition Unblocked Date

2025-07-07

Earliest Breaking Changes Unblocked Date

2025-07-07

Earliest Open edX Named Release with Breaking Changes

Ulmo - 2025-10

Rationale

This is not exactly a DEPR, but I'd like to use the DEPRs inform and approval process. Additionally, this was almost a fast-track (breaking change) DEPR, but again, I first wanted feedback and approval on the plan.

Currently, the SAMLProviderConfig holds a reference to a SAMLConfiguration. Additionally, the SAMLConfiguration is a ConfigModel, and in theory, and only its current or latest value should be in use. However, the SAMLProviderConfig points to a specific row of the SAMLConfiguration, which will be outdated as soon as the SAMLConfiguration gets updated.

In order to get the latest update for the SAMLConfiguration in all the SAMLProviderConfigs that point to it, one needs to manually update each SAMLProviderConfig to point to the newer SAMLConfiguration. At one point, this caused a production issue at 2U, because this was not clear or obvious to someone updating a SAMLConfiguration.

Initially, this seemed like a clear bug. Instead of holding on to an outdated SAMLConfiguration, it seemed like each SAMLProviderConfig should be updated to point to the latest SAMLConfiguration when a SAMConfiguration is updated. Although this still seems right, it did occur to me that this would be a breaking change for anyone who was relying on the current process, where the SAMLConfiguration could be updated, but the update wouldn't go into effect until the SAMLProviderConfig were updated.

Sp, this proposal is to draw attention to this breaking change, and to ensure there are no objections to the configurations automatically using the current/latest config (as intended by ConfigModels), rather than relying on manual updates and possibly pointing to outdated SAMLConfiguration values.

Removal

Here is the reference to the SAMLConfiguration:

• edx-platform/common/djangoapps/third_party_auth/models.py

  Line 777 in b8534a6

  saml_configuration = models.ForeignKey(

The proposal is not to remove this reference, but simply to auto-update it when a SAMLConfiguration get updated.

Replacement

Again, the replacement of the manual updates to these references will instead be an automatic update to the SAMLConfiguration reference.

Deprecation

No response

Additional Info

No response

Task List

• Land a fix with a temporary rollout toggle for testing.
• Remove the temporary rollout toggle.
• Update named release docs

Task List

No response

[kdmccormick]

Sure, that sounds like a good fix.

Meta: By the logic of this, every bugfix could be a breaking change, in that it breaks someone who depends on the bugged behavior, right?

[robrap]

Meta: By the logic of this, every bugfix could be a breaking change, in that it breaks someone who depends on the bugged behavior, right?

Possibly, but I think it needs to be a case-by-base question. Usually, one would just fix the bug, as you are noting. I figured worst case this would be an inform. I possibly someone would appreciate the warning around this change.

[zamanafzal]

Thank you, @robrap, for proposing this. I’m trying to understand the flow where this caused a production issue at 2U. Since the FK already limits choices to current SAMLConfigurations using active_saml_configurations_filter(), don’t you think the existing approach is sufficient and no changes are needed?

[robrap]

@zamanafzal: Here is what happened:

1. A SAMLConfiguration was created (or existed).
2. A SAMProviderConfig was set up pointing to the active SAMLConfiguration.
3. Either a misconfiguration was discovered, or a change was needed in the SAMLConfiguration.
4. The SAMLConfiguration was updated to fix the issue.
5. The SAMLProviderConfig continued to point to the outdate SAMLConfiguration row without the fix, and thus the updated config was not applying, and not resolving the issue.
6. It was finally discovered that the outdated config was in use, and the SAMLProviderConfig was manually updated to point to the now updated SAMLConfiguration, and this resolved the issue.

The proposal is to have the SAMLProviderConfig automatically update to point to the latest on changes to the SAMLConfiguration, in order to avoid points 5 and 6 above.

[zamanafzal]

@robrap That makes sense. I had assumed we were always using the latest configuration for all SAMLProviderConfig instances.

[robrap]

Great. Thanks @zamanafzal. That confirms that this probably doesn't require more approval time, and no one is relying on the broken behavior, because everyone assumed this just worked as expected.

@kdmccormick: I was considering making this a fast-track auto-accepted ticket, but I wanted some room for approval. Now that both you and @zamanafzal confirmed that this can just be thought of as a bug fix, I will probably accept this early (if we get a fix completed before July-7, which is already under review).