Conversation
…n NoAuthnContext errors
…in SP configuration.
Yes, this is required by the specification. They should respond with a SAML NoAuthnContext exception.
No, that would be bad practise and would open up for an entire new attack vector > downgrade attacks.
That's a fair approach, but the selection should be done before a request is sent, based on a mapping table. Imagine what it would do to the IDPs logfiles if some SP is throwing a bunch of requests with unsupported AuthnContexts at them.. Every IDP of federation should have a publicly available list of supported AuthnContexts (LIke i.e. https://refeds.org/profile/mfa) So while I understand your problem, I don't think this is the right approach. A mapping table in the metadata would make a lot more sense. |
|
I'm kind of lost in what this is trying to accomplish now. To me the original PR/goal was to automatically handle the "MFA with Retry" from Refeds Wiki ( https://wiki.refeds.org/pages/viewpage.action?pageId=77465130), where MFA context is desired, but not required, and you start with requesting the desired context, and fall through to other acceptable contexts if the IdP does not support, or does not support for that user, the initially requested contexts. |
3 participants
Use Case:
When our system acts as a proxy, customers often want to request strong authentication methods (like MFA) without making them strictly mandatory. Currently, if we ask for a specific method, some Identity Providers (IdPs) will simply throw an error if they don't support it. On the other hand, if we ask for multiple methods at once, IdPs often default to weaker options like passwords. To follow best practices, we need a way to try one authentication method at a time. If an IdP rejects our first choice (like phishing-resistant MFA), the system should automatically step down and try the next option, eventually falling back to a standard login if needed.
Implementation:
To make this possible, we updated the code to support a sequential fallback mechanism for authentication requests. When the system receives an error from an IdP, it will now automatically retry the login using the next context in our fallback list. We also fixed a few important edge cases for when the system is operating as a proxy. Specifically, we made sure that the system doesn't get stuck in an endless loop by prioritizing the active fallback attempt over standard configurations. Additionally, we ensured that on the final fallback attempt (when no specific method is requested), the original service provider's request doesn't accidentally interfere, allowing the login to proceed smoothly.This PR introduces a pre-flight mapping mechanism (
AuthnContextClassRefMapping).Context selection is evaluated before the authentication request is ever sent to the IdP. By defining an
AuthnContextClassRefMappingtable in the global SP configuration or directly in a specific IdP's remote metadata, the proxy can intercept the requested contexts and translate them into contexts that are actually supported by the upstream IdP.This allows the system to seamlessly step down (e.g., mapping phishing-resistant MFA to standard MFA) or drop the requirement entirely (falling back to standard password login) cleanly and efficiently. The mapping happens dynamically per IdP, preventing invalid requests, mitigating downgrade attack risks, and avoiding broken login flows. This PR also includes comprehensive unit tests and documentation detailing how to configure these mappings.