Support alternate SAML auth flow with ForceAuthn query param (PP-4792)#3574
Conversation
|
Claude finished @tdilauro's task in 4m 17s —— View job Code ReviewI reviewed the diff against DetailsNit:
|
Greptile SummaryThis PR adds support for an optional
Confidence Score: 5/5Safe to merge; the new code path is additive, correctly guarded, and fully exercised by tests. The feature is purely opt-in (defaults to False), so existing flows are unaffected. Validation of the query parameter happens before any IdP round-trip and uses an explicit allowlist. The force_authn flag is forwarded to the python-saml library's login() method, which has supported this parameter for years. Test coverage is thorough — valid, absent, and several invalid values are all exercised, and the SAML XML attribute is verified at the byte level. The only observation is a leftover pd alias in finish_logout's return annotation that was not updated alongside start_logout in the same file. No files require special attention. Important Files Changed
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3574 +/- ##
=======================================
Coverage 93.51% 93.52%
=======================================
Files 512 512
Lines 46754 46760 +6
Branches 6378 6379 +1
=======================================
+ Hits 43722 43731 +9
+ Misses 1960 1958 -2
+ Partials 1072 1071 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Both Claude and greptile don't like my extra problem detail alias (great that they agree on something 🙄), but I didn't like |
jonathangreen
left a comment
There was a problem hiding this comment.
I support this revolution against the robots! 🤖
Description
force_authnquery parameter ("true"or"false") on the SAML authentication redirect endpoint.force_authn=trueis requested, the generated SAMLAuthnRequestsetsForceAuthn="true", instructing the identity provider to re-authenticate the patron even if the patron already has an active IdP session (SAML 2.0 Core 3.4.1).Motivation and Context
A patron with an existing IdP session for the wrong account can get stuck at sign-in. For example, when a patron is signed into a Microsoft account from a different tenant, Microsoft may silently reuse that session and fail with an unrecoverable
AADSTS50020error instead of prompting for credentials. This gives clients (e.g., Palace Web Catalog) an escape hatch: an alternate sign-in path can be used to force the IdP to present a fresh login prompt.ForceAuthnis part of the SAML 2.0 Core specification, so it is supported across the identity providers we integrate with, unlike vendor-specific alternatives.[Jira PP-4792]
How Has This Been Tested?
Checklist