cantor.2 at osu.edu
Thu Sep 26 19:13:20 EDT 2019
On 9/26/19, 6:44 PM, "users on behalf of Doan, Tommy" <users-bounces at shibboleth.net on behalf of tdoan at smu.edu> wrote:
> I’m experimenting with p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT" in relying party. I happened
> to notice that one particular SP, Handshake, sends what appears to be an unusual RequestedAuthnContext in the
It's invalid, not unusual.
> That Comparison=”exact” parameter is disallowed and logged by the IdP as expected, but the SP then throws an error.
> So there doesn’t appear to be a way to interact with this SP with disallowedFeatures-ref in place.
The purpose of disallowing it is to reject any request that carries it, the error is returned from the IdP. By definition you cannot interact with it.
> The reason I’m working with disallowedFeatures-ref is to determine how best to require MFA for lots of SPs, and
> eventually all of them, through relying party configuration. It seems like a good idea to use disallowedFeatures-ref in
> that strategy
It's required, not just a good idea. Without it, they can simply circumvent it, and so can any attacker.
> and I’m not sure what to do about an SP like Handshake.
Report a bug. Either accept that the MFA requirement will be meaningless, or they have to fix it so you can implement the safeguard.
> I understand an SP asking for a specific authn context, but that’s not really even being done here.
It's a bug that it's not rejecting the request outright no matter what. The IdP is more forgiving than I would have been had I written the original XML processing code. The SP is more strict and rejects empty elements like that.
More information about the users