idp v3.1: defaultAuthN method for default RP?

[Cantor, Scott]

On 3/13/15, 6:09 AM, "Misagh Moayyed" <mmoayyed at unicon.net> wrote:

>What happens when I have no RequestAuthnContext and my profile configuration does not define any default authentication methods? Will I need to specifically set the default authn method for the profile, or can
> this be set for the RP itself “globally”?

It's unspecified, the same as it was in V2. If you specify nothing in the configuration, then the IdP will walk the list of configured login flows and pick one to run. Some of the flows can stack (e.g. the IPAddress handler can try to run and just fail silently if not and fall into the next method) while others will basically take over and either work or fail, like a form login.

Out of the box, it's basically going to try the Password method since all that's really enabled.

> 
>I understand I could probably wire this all up via some Spring magic to not have duplicate configuration for each RP, but is there a different way?

Not if you need to support multiple login flows but still default the choice to run. It can't read your mind.

You can actually specify methods in terms of SAML methods or context classes with the defaultAuthenticationMethod property, or you can enable specific login flows per-profile directly in a more low level way with the "authenticationFlows" profile property.

One is abstracted away from the flows and the other is directly in terms of flows. Most of the time it's easier to just specify the flow(s) directly, but really in most cases, if you have multiple flows, you probably have no apriori way to know which one to use anyway. Multiple methods is a complex thing to support and use, and it will always be complex. It's just a hard thing. Typically you're talking about use cases such as Paul's MCB supports now, so now you're talking about a lot more stuff. Resolving attributes up front to identify methods based on the user, filtering flows against an attribute, possibly doing "initial" authentication via a password and then branching, etc.

-- Scott