RequestedAuthnContext with a Comparison="maximum"

[Benjamin Lewis]

Hello,

We are also dealing with this situation, probably due to the same SP.
 
Scott Cantor wrote:
> On 9/21/16, 8:26 AM, "users on behalf of Youssef  GHORBAL" <users-bounces at shibboleth.net on behalf of youssef.ghorbal at pasteur.fr> wrote:
> 
> > 	I have a mobile app that initiates Authn requests with an RequestedAuthnContext set
> > like this :
> 
> Deliberately? If so, why? If this isn't deliberate, the proper thing to do is to fix the bug.

In our case, the application is a mobile app running on iOS and Android devices. Our assumption about the reasoning behind including the RequestedAuthnContext with the particular maximum they chose is to prevent ADFS IdPs from trying SPNEGO/Kerberos authentication for this application. That is just speculation on our part at this time.

> >	Since the app seems to express a “maximum” requirement, I think that it would be
> > suffisient for it to have ProtectedPassword context (is that what is meant for “maximum”?
> 
> It is impossible for the IdP to honor anything but exact unless you teach it how to do that for the values you have to support. This isn't an AI. It doesn't know what any of the strings mean.
> 
> >	To deal with the situation, and since I’m not intending to add support for x509 auth
> >anytime soon, I was thinking going lazy and simply ignore the AuthnContextClassRef of value
> > "urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient” using the 3.2 feature
> > (shibboleth.IgnoredContexts in authn/authn-comparison.xml) 
> 
> That is not the proper way to fix it. You need to teach it the relationship between the values you do support and the value(s) being requested using the comparison beans provided for that purpose.
> 
> But that's all silly. The application is broken. Tell them to fix it.

If we were to attempt to configure our Shib 3.2.1 IdP to do a "maximum" comparison, given that we're using ShibCas from Unicon, do the following changes in authn-comparison.xml seem reasonable?

    <bean id="shibboleth.MaximumClassRefMatchFactory" parent="shibboleth.InexactMatchFactory">
        <property name="matchingRules">
            <map>
                <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
                    <list>
                        <value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
                    </list>                                                                             
                </entry>                                                                                
                <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient">
                    <list>                                                    
                        <value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
                    </list>                                                                             
                </entry>                                                                                
            </map>         
        </property>     
    </bean>        

  <entry key-ref="shibboleth.SAMLACClassRefMaximum" value-ref="shibboleth.MaximumClassRefMatchFactory"/>

Since we have basically just one AuthnContext available at this time, the idea of the above is to basically duplicate the degeneration into the exact matching that we had with the default configuration and also allow the authentication to proceed in our new situation. I assume that a more correct way to do it would include all of the other types as similar entries in the map.

Am I barking up the right tree with the above?

Thank you in advance for any advice you can give us,
-Ben