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

[David Walker]

On 07/11/2015 02:16 PM, Cantor, Scott wrote:
> On 7/10/15, 6:22 PM, "David Walker" <dhwprof at gmail.com> wrote:
>> 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.
> I know, unfortunately that's "hard". Not impossible, but it's a lot of work.
>
>> 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.
> It's not impossible that Marvin's right and these SFA flows like Duo really are intercepts, not login flows. They may work better as special add-ons that run afterwards and do some fairly ugly things internally but avoid making the login layer a lot more complex just to accomodate them. I'm not happy with that answer exactly, but I don't know if any the options will make me very happy.

Yeah, these second-factor technologies (Duo, U2F, Toopher,...) broke a
lot of assumptions, but they seem to be popular.

>> 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.
> Sure it would. Lots of resolver configs do special things based on the SP.

Hmmm...  I guess you're right.  My guess is they'd also have access to
the SP's authnContext request; would they also have access to the other
context the IdP might use to satisfy the request (as specified in
authn-comparison.xml)?

>
> -- Scott
>