RequestedAuthnContext Comparison="exact"

[Doan, Tommy]

I contacted Handshake support about the problem, and they pointed me to their SSO documentation. 
https://support.joinhandshake.com/hc/en-us/articles/360012404753-SSO-Setup-Guides-SAML-Configuration-ADFS-Claim-Rules-Guide-Example 

At the bottom of that support page, there's a reference to a configuration checkbox labeled Requested authentication context. The strange thing is there actually is no option there to specify a requested authn context. The only thing that checkbox appears to do is to cause the AuthnRequest to include a parameter of the RequestedAuthnContext to say that the provided context must be an exact match. There is no way to indicate what the comparison should be made to. This seems like a mistake to ever have enabled, and I've given them that feedback.

The documentation did make me realize that option was in fact enabled on our instance, and after disabling it the RequestedAuthnContext is now removed from the AuthnRequest, and the problem is resolved. 

<samlp:AuthnRequest AssertionConsumerServiceURL="https://app.joinhandshake.com/saml_consume"
                    Destination="https://idp.smu.edu/idp/profile/SAML2/Redirect/SSO"
                    ID="_395fb93d-9196-45ac-b254-e3fb1ba23bf0"
                    IssueInstant="2019-10-01T19:26:33Z"
                    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:AuthnRequest>

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, September 26, 2019 6:13 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: RequestedAuthnContext Comparison="exact"

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


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net