RequestedAuthnContext with a Comparison="maximum"

[Cantor, Scott]

On 9/21/16, 10:55 AM, "users on behalf of Benjamin Lewis" <users-bounces at shibboleth.net on behalf of bhlewis at bhlewis.me> 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.

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

I didn't thnk ADFS supported inexact RequestedAuthnContext matching, but that could be incorrect.

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

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

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.

You don't have to include any SAML 1 AuthenticationMethods since those would never be referenced by a SAML 2 request.

-- Scott