RequestedAuthnContext with a Comparison="maximum"

[Benjamin Lewis]

Scott,

You wrote:

> On 9/21/16, 10:55 AM, "users on behalf of Benjamin Lewis" wrote:
>
>> In our case, the application is a mobile app running on iOS and
>> Android devices.
>
> Well, it can't be the app, it would need to be an SP it's communicating
> with. If it were the app itself, there's a much bigger problem to deal with.

Yes, that's true. The app is communicating with the SP via a built-in
browser of some sort and then is being redirected to our IdP with an
AuthnRequest in hand.

>>    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?
>
> Yes, assuming all you support is one context class.

We do support the two classes you name below so there is more to do.

>> I assume that a more correct way to do it would include all of the
>> other types as similar entries in the map.
> 
> The types you have to include are the classes you indicate support for
> in your authentication flow configuration as supported principals. It
> would be a mistake to do otherwise and there's no reason to since it's a
> finite set. Normally that's just Password and PasswordProtectedTransport
> unless you're using more exotic methods or values.

That makes me think that I have the totally wrong mental model for this.

What I've been thinking is that we'd want an entry in the map for every
class that we consider to be at least as strong as one of the two SAML2
classes we actually do support so that we can proceed with using the
strongest class we do support that is less than or equally strong.

We wouldn't list classes that were not as strong as our weakest supported
class because we'd have no available classes that were weak enough to
satisfy the request.

So, my thought was that we'd end up with something like:

  <bean id="shibboleth.MaximumClassRefMatchFactory" parent="shibboleth.InexactMatchFactory">
    <property name="matchingRules">
      <map>
        <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:Password">
          <list>
            <value>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</value>
          </list>
        </entry>
        <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:InternetProtocolPassword">
          <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>
        <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:X509">
          <list>
            <value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
          </list>
        </entry>

[ ... yada yada yada through most of the rest of section 3.4
 of the saml-authn-context-2.0-os document ]

        <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken">
          <list>
            <value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
          </list>
        </entry>
      </map>
    </property>
  </bean>

Am I off in left field here?

Thank you,
-Ben