Add support for defaultAuthenticationMethod

[paulhethmon]

Shibboleth relying party configuration allows a default authentication method to be specified per relying party. Make use of the default value when a RP does not send a method (context) with their request.

Still outstanding is whether to use the default method when the RP does send a value. If so, does it get added to the beginning or the end of the list?

[langedb]

If there is a default supplied by the IdP and the RP sends an explicit contextClassRef in the request then we need to honor the explicit request by the SP rather than do what the IdP has specified by the default.

[langedb]

Thinking about this a little more, there are two scenarios affecting this RFE

1 SP does the wrong thing & IdP wants to enforce policy.

Use Case

IdP wants to force 2FA for a SP, but the SP insists on sending PasswordProtectedTransport. Due to clueless vendor the vendor can't / won't change the AuthnContextClassRef requested in the AuthRequest. Therefore IdP would want the relying-party.xml default to override.

2 SP is well-behaved and actually wants to offer 2 levels of authN

Use Case

IdP default is PasswordProtectedTransport and SP sends unspecified. When the user tries to do something requiring a better auth level (like change their direct-deposit) then the SP will send a new AuthRequest with 2FA, and needs the IdP to respect/perform that.

[dhwalker]

I've been uncomfortable about the first use case, but I guess we allow
the idP to override an SP's request in other situations (by defining
other contexts that satisfy what the SP requests), so I guess I'm OK
with doing something to allow an override. How would the configuration
work, though, since there's already a configuration option with no override?

Do we need to do anything to make the second use case work? Doesn't it
work this way now without specifying a default context for that RP?

David

On 07/19/2014 05:40 PM, David Langenberg wrote:

Thinking about this a little more, there are two scenarios affecting
this RFE

1. SP does the wrong thing & IdP wants to enforce policy.

   Use Case

IdP wants to force 2FA for a SP, but the SP insists on sending
PasswordProtectedTransport. Due to clueless vendor the vendor can't /
won't change the AuthnContextClassRef requested in the AuthRequest.
Therefore IdP would want the relying-party.xml default to override.

1. SP is well-behaved and actually wants to offer 2 levels of authN

   Use Case

IdP default is PasswordProtectedTransport and SP sends unspecified.
When the user tries to do something requiring a better auth level
(like change their direct-deposit) then the SP will send a new
AuthRequest with 2FA, and needs the IdP to respect/perform that.

—
Reply to this email directly or view it on GitHub
#11 (comment).

[paulhethmon]

Fixed in version 1.2.1