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

[David Walker]

On 07/10/2015 11:49 AM, Cantor, Scott wrote:
> 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.

Yeah, I was never happy with the solution, either.  When we found out
how Duo works, we already had the initial authentication concept
(because some people didn't want to reveal information about other
authentication methods until /some/ form of authentication had been
done), and we realized that it could address the common Duo use case
while making SSO work as expected.

You can, of course, specific multiple possible initial authentication
methods, like password and true MFA, but that gets you back to having
your users make decisions.  As I said before, I think a better solution
would be to have some way for a second factor only flow like Duo specify
in its configuration that some other predecessor authentication flow
must be run first.  Of course, that could all be put into the Duo flow,
but then it would be hard to make SSO for that predecessor flow work.

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

Thanks.

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

Yeah, using the attribute resolver is a popular way to do it, and it
does handle many use cases.  I think, though, that wouldn't allow a
filtering policy that's based on the SP, as well as the user.  (/E.g./,
user X is required to use MFA only when accessing SP A or B, if I
remember Scott Koranda's use case right)  If you squint at it, the
choice menu is also a form of filtering, so I saw this as way to handle
the broader set of use cases.

> -- Scott
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150710/60255b12/attachment.html>