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

[Kaspar Brand]

This came up in a thread in April already [1], but I wonder if it could
be "fixed" by making the default v3 configuration somewhat more
permissive: an AuthnRequest which includes

<samlp:RequestedAuthnContext>
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef></samlp:RequestedAuthnContext>

will trigger an error status with the v3 default configuration
(urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext, "None of the
potential authentication flows can satisfy the request" in the IdP log).

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

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?

Kaspar


[1] https://shibboleth.net/pipermail/users/2015-April/020722.html

[2] https://shibboleth.net/pipermail/users/2015-April/020882.html