feat: Enhance SAML provider name resolution & update redirect handling

[bra-i-am]

Description

Fixes an issue where the TPA errors during the "link account" flow from the Account MFE were skipped, leaving the user with no feedback.

Root cause

When a SAML authentication error occurs (e.g. AuthAlreadyAssociated — the IdP account is already
linked to a different platform account), ExceptionMiddleware.get_redirect_uri() returned
/account/settings. That path is registered as a plain
django.views.generic.base.RedirectView pointing directly to ACCOUNT_MICROFRONTEND_URL. This
redirect is stateless — it does not read or forward Django messages, nor does it preserve query
parameters — so any error context was lost before the MFE ever loaded.

What changed

common/djangoapps/third_party_auth/middleware.py

• Added _get_saml_provider_name(request): reads the RelayState field from the SAML POST body
  (which contains the IdP slug as {"idp": "<slug>", ...}), looks up the corresponding provider in
  the TPA registry, and returns its human-readable display name (e.g. Cartão de Cidadão). Falls
  back to None gracefully on any parsing or lookup failure.

• Extended ExceptionMiddleware.get_redirect_uri(): when auth_entry == account_settings and the
  exception is a SocialAuthBaseException, the method now bypasses /account/settings and builds
  the Account MFE URL directly with ?duplicate_provider=<name>, using urllib.parse.quote() to
  encode the name as %20-spaced (not +-spaced) so the MFE renders it correctly. Falls back to
  the backend name (tpa-saml, OAuth provider name, etc.) if the SAML provider name cannot be
  resolved.

The Account MFE (frontend-app-account) already reads ?duplicate_provider= in
AccountSettingsPage.jsx and renders a danger alert — no frontend changes were required.

Impact

• Learners: The error message "The [Provider Name] account you selected is already linked to
  another [Site Name] account." is now correctly displayed in the Account MFE after a failed link
  attempt.
• Operators / Developers: No configuration changes required. The fix activates automatically for
  any auth_entry=account_settings TPA error.

Screencast

Screencast.from.01-04-26.09.03.33.webm

---

Testing instructions

*This change was tested by using SimpleSAMLphp

1. Configure two platform accounts (user_a@example.com, user_b@example.com) and a SAML IdP.
2. Link the SAML identity to user_a via the normal login flow.
3. Log in as user_b.
4. Navigate to Account MFE → Linked Accounts.
5. Click "Sign in with <Provider Name>" for the same SAML IdP.
6. Complete authentication with the same identity on the IdP side.
7. Expected: Account MFE reloads and shows a red alert:

   "The [Provider Display Name] account you selected is already linked to another [Site Name]
   account."

[openedx-webhooks]

Thanks for the pull request, @bra-i-am!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[Gi-ron]

_get_saml_provider_name within the middleware to construct a direct URL to the MFE with ?duplicate_provider=. While this resolves the specific SAML case, I'm a bit concerned about extensibility and long-term maintainability. I'd like to share why I think it would be better to move this logic to a custom view (such as AccountSettingsRedirectView) that handles the error context in a more generic way.

[Gi-ron]

Hey, just a thought on this — I think we could improve the overall design by moving the redirect logic to a custom view (e.g. AccountSettingsRedirectView) instead of handling it inside the middleware. Here's my reasoning:

• Centralizes redirect logic: The view would be responsible for reading error messages from django.contrib.messages (or the session) and deciding how to pass them to the MFE. That way the middleware only needs to store the error (e.g. via messages.error(...)) and doesn't need to know anything about URL construction.

• Extensible to any provider: Any backend (SAML, OAuth, LTI) can add a message with extra_tags='social-auth' and the view will pick it up automatically — no need for provider-specific helper functions like _get_saml_provider_name.

• Cleaner separation of concerns: The middleware handles exceptions and stores errors; the view handles the redirect and forwards the error to the MFE. This makes both pieces easier to test and reason about independently.

• Easier to evolve the MFE communication layer: If we ever decide to switch from URL params to an API endpoint, we only update the view — not the middleware. For example, the view could store the error in the session and the MFE could fetch it via a call to /api/user/v1/tpa_errors/.