MDDriven overrides for defaultAuthenticationMethods
Michael Grady
mgrady at unicon.net
Thu Nov 25 01:27:39 UTC 2021
> On Nov 24, 2021, at 6:14 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 11/24/21, 6:23 PM, "users on behalf of Andrew Jason Morgan" <users-bounces at shibboleth.net on behalf of morgan at oregonstate.edu> wrote:
>
>> What happens if I don't set defaultAuthenticationMethods in the DefaultRelyingParty? I have
>> idp.authn.flows=MFA, and I have defined the supportedPrincipals for authn/MFA. Do I need to "turn off"
>> other flows at all? I wonder if my defaultAuthenticationMethods setting is just vestigial at this point....
>
> They're for different purposes. The supportedPrincipals property of a login method determines what that method supports so that if something is requested, it knows whether it should try that flow. It generally also auto-populates the result of the flow with those classes.
>
> The defaultAuthenticationMethods property is an IdP-side imposition of a requirement that takes the place of an SP requesting something and is basically in SAML terms the same as if the SP requested an exact match of one of those classes.
>
> Setting anything on the DefaultRelyingParty beans applies if there's no override that directs it to use a different configuration. An override could take effect, and if metadata is involved, the metadata would apply, but only if the override did. Otherwise the default would apply and the explicit setting there would win.
>
> Combining things gets tricky, but is deterministic.
>
>
You could define a custom entity attribute to add to those SPs where you want to override the AuthnMethod in the metadata, and then define a single override that applies to any SP tagged with that custom entity attribute, uses the SAML2 MDDriven bean, and does NOT itself have an AuthnMethods property set on it.
--
Michael A. Grady
IAM Architect, Unicon, Inc.
More information about the users
mailing list