Backward-incompatible handling of the "unspecified" authentication context class with the IdP v3 default configuration

[Cantor, Scott]

On 7/27/15, 10:13 AM, "users on behalf of Kaspar Brand" <users-bounces at shibboleth.net on behalf of kaspar.brand at switch.ch> wrote:
>
>One of the upgraded IdPs in our federation is running into this problem
>with SpringerLink (http://link.springer.com/athens-shibboleth-login),
>and while there is no doubt that the RequestedAuthnContext they include
>doesn't make any real sense, it's also kind of a backward
>incompatibility with the IdP v2 (which simply disregards
>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified and continues with
>the authentication).

Yes, it's a bug. I thought we were ignoring it. I don't remember that thread or why I would have treated it as intentional. Please file a bug on it.

>We can work around this by telling the IdP admins in our federation to
>tweak conf/authn/general-authn.xml (as suggested in [2]) - or trying
>to get the SP "fixed" -, sure, but wouldn't it make more sense to add
>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified to the
>shibboleth.AuthenticationFlow bean in
>system/conf/general-authn-system.xml, so that such AuthnRequests are
>just routed to the "default" flow ("authn/Password", as configured in
>idp.authn.flows)? I.e., if an SP calls for "unspecified", then just
>serve his request with a password-based authentication context?

If we required people modify user files to fix it, it would essentially never be fixed since those aren't automatically updated on upgrades. Just needs to be fixed in the code, or made an option.

-- Scott