RequestedAuthnContext Comparison="exact"

[Doan, Tommy]

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.

<samlp:AuthnRequest AssertionConsumerServiceURL="https://app.joinhandshake.com/saml_consume"
                    Destination="https://idp.smu.edu/idp/profile/SAML2/Redirect/SSO"
                    ID="_fc6603c3-2218-4356-b219-09bf43b04bd8"
                    IssueInstant="2019-09-26T22:03:31Z"
                    Version="2.0"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    >
    <saml:Issuer>https://app.joinhandshake.com/sp</saml:Issuer>
    <samlp:NameIDPolicy AllowCreate="true"
                        Format=""
                        />
    <samlp:RequestedAuthnContext Comparison="exact">
        <saml:AuthnContextClassRef/>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

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 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, and I'm not sure what to do about an SP like Handshake. I understand an SP asking for a specific authn context, but that's not really even being done here. Maybe it's unintentional or a configuration error. Is the only option to take this up with the SP admins, or is there another approach on the IdP side to prevent an authn context request from interfering with the relying party configuration to require MFA?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190926/a67a19d8/attachment.html>