Mapping multi-context-broker.xml to Shibboleth IdPv3 Configuration

[Cantor, Scott]

On 7/10/15, 12:02 PM, "users on behalf of David Walker" <users-bounces at shibboleth.net on behalf of dhwprof at gmail.com> wrote:

>Right, so if the attributeResolverID were also configured, it would be considered in conjunction with defaultAuthenticationMethod when selecting feasible flows?  (By "feasible," by the way, I mean the flows that meet, as determined by IdPv3's existing logic, the needs of 1) the SP's request, and 2) how the user has been allowed to authenticate from the attributeResolverID.)

Yes, provided you're willing to force people to login in a specific way first, and that's the part I think falls down pretty hard in all this work. Marvin already identified the problem with that. It works fine for sites that essentially have two methods, password and something that supplements a password. If you add certificates or true MFA to the mix, I think it falls down.

>OK, I think I've got the basic idea.  I assume the "feasible" flows would be available in the context tree?

Yes, the AuthenticationContext (ours, not SAML's, the name conflict is unfortunate) contains the list of flow descriptors that haven't been filtered out.

>Yeah, I'm coming to that conclusion, too, although I could see the potential for providing choices in the future, for example, at a time that a site is migrating from one MFA product to another.  I've seen examples of the more general case, though, of applying site policy to the list of feasible authentication methods (e.g., requiring MFA at certain times of the day or at certain IP addresses), so knowing how to do it is still important.

We can add more extensible "filtering" to the login flow set if we need to. It can be done now, it's just more invasive to system files. Of course, you can also implement that sort of logic in the attribute resolver when you resolve an attribute for the user to use to filter flows.

-- Scott