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

[Cantor, Scott]

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

>I've posted a DRAFT document describing conversion from the Multi-Context Broker (MCB) to IdPv3 at
>https://wiki.shibboleth.net/confluence/x/oAEzAQ.  It's not yet complete, and I'm sure it has errors, so I'd appreciate a glance from some more knowledgeable eyes than mine.  You'll see some comments
> in red that are open issues right now.

I have vacation days and SP matters to deal with so it will be a while before I have time to review it.

>* I believe IdPv3 bypasses the processing of authnContexts if the SP does not request any contexts.  Since one of the use cases is to allow institutions to require that certain people use multi-factor authentication (or allow users to opt-in to such a requirement),

My assumption was that that would involve filtering login flows based on an attribute. Users that require MFA would only carry that flow ID in the attribute, so it would prevent use of auth/Password. That was the reason for the "initial authentication" stuff, to get the user ID so the attribute can be resolved.

> I'm looking for  a way to force that processing?  For example, is it possible to define a default relying party that "requests" the institution's lowest-level authnContext?

Profile configuration beans that involve authentication (i.e. the SSO profiles) have two properties:

authenticationFlows (Set<String>)
defaultAuthenticationMethods (List<Principal>)

The former will specifically turn on and off login flows by flow ID directly. The latter is analagous to the defaultAuthenticationMethod in V2 and acts as a pseudo-RequestedAuthnContext. That's closer to what you're driving at. It acts as if the SP sent a request for an exact match to one of the custom Principals specified. It's slightly stronger in meaning than that V2 setting was because it really does require the authentication result end up with a matching Principal, as if an SP requested it.

But that's not user-aware, only relying party aware.

>* You'll notice that a number of the red comments are related to the MCB's ability to present the end user with a choice of feasible authentication methods, rather than picking one at random.  Scott, I have a memory that you said there was a hook that could be used to implement that choice mechanism; can you point me in the right direction?

A custom login flow that doesn't actually do much itself, and just renders a view-state with links/buttons that signal what flow to run next, which I documented the mechanism for in the wiki page on authentication.

The flow would I guess be the first one listed in the descriptor list and would carry every possible supportedPrincipal needed so that any request for any method would route into it. That was and is all hand waving. I don't know how much work it would be to figure out which options to present the user because I don't really know what the inputs to that decision would be.

>I'm thinking it would be a "choice" flow that could be invoked after the IdP had determined the feasible flows that can be used, based on the SP's request and the user's allowable contexts.  The "choice" flow would then select which of the feasible flows to invoke, based on prompting the user or any other policy the site might want to implement.

Yes, basically. That's why I implemented a mechanism for a login flow to signal for another one to run.

"Magic happens" and that view has to be rendered with enough logic to make all those determinations based on what's in the context tree, which is full of all kinds of information. Might need to be a JSP view to be palatable to code it. Velocity isn't that great for doing a lot of logic.

>* Related to my previous question, does anyone have a use for presenting such a choice?  I thought it was important when spec'ing the MCB, but I've found that many sites go to lengths to turn it off.

Personally, I think it's better for the user to route to actual usable login interfaces and give them buttons to transfer to others than to force a list up front. Particularly if there's an 80% or 90% case anyway, which seems likely. As other people have done, you can drop cookies to record choices and change which one is used for a user by default the next time.

-- Scott