RequestedAuthnContext Comparison="exact"

[Cantor, Scott]

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
> AuthnRequest.

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.

-- Scott