Preliminary Gap Analysis for Replicating MCB Functionality in Shibboleth v3

Paul Hethmon, Scott Cantor, and David Walker have discussed Multi-Context Broker (MCB) functionality and how to bring it to Shibboleth v3, largely based on the information in AuthenticationConfiguration for Shibboleth v3, and Multi-Context Broker and Assurance Enhancements for the Shibboleth Identity Provider (19 April 2013) for Shibboleth v2. While we do not have all the answers yet, this is a quick assessment of the issues.

The goal is to make MCB functionality available in Shib v3, not necessarily to replicate the format of configuration files, etc. We will provide documentation and tools to ease the transition, but it is not a requirement to enable a transition to v3 without effort on the part of the Shibboleth system administrator.

The following table lists the elements of the MCB's functionality along with current v3 status.

	MCB Functionality	Shibboleth v3 Status	Thoughts about Resolution
1	Selection of potential authentication methods on the basis of an SP's request.	Currently in v3.
2	Ability to configure authentication contexts that satisfy the requirement of other contexts.	Currently in v3.
3	Selection of potential authentication methods on the basis of user certifications.	Currently in v3.
4	Ability to configure the same authentication method for multiple authentication contexts.	Currently in v3.
5	Ability to configure "initial" authentication contexts. The user must authenticate to one of them before the MCB processes the IdP session's first request from an SP.	Currently in v3, with a primary difference that v3 ignores SP and configuration rulesets about which methods to choose from, and requires a statically configured invariant list of initial methods. Scott believes this is clearer and simpler to understand, and creates fewer edge cases to code for.	From Scott's comments, I'm not sure how v3 differs from the MCB. Perhaps that the MCB allows the user to choose from multiple initial contexts, whereas v3 does not? (DW) --- Do we know anyone who has configured the initial authn to be other than standard username/password? We haven't in the deploys we've been involved in. (MG).
6	Configuration option to specify whether authentication should succeed or fail when a user has no context certifications and the SP does not request a specific context.	Not currently in v3. Do we need this? Scott strongly suggests not introducing hard to diagnose error-causing behavior when a simple login is allowed by the SP.	Which option are sites specifying? If all the same, we probably don't need this. (DW)
7	Configuration of the maximum number of authentication failures that can occur before failure is returned to the SP. In this context, an authentication failure is a failure return from an authentication method to the MCB (so the MCB can present alternative methods); each authentication method has the potential of allowing some number of tries, as well.	Not currently in v3. Scott is looking at how to do this, but is a little unclear on the requirements. [The MCB counts the number of times authentication methods are invoked and will give up if this configured number is exceeded. This is really just an attempt to give the user some recovery if they choose the wrong authentication method without letting them get stuck if they can't use any offered method. The number is also only approximate, as authentication methods are not prohibited from allowing multiple attempts before returning to the MCB. I suppose it might be OK not to allow the selection of another method and simply return failure to the RP under the assumption that the RP will let the user try again. - DHW]	I'm thinking we don't need this. (DW)
8	Configuration of friendly names for authentication methods to be used when the MCB presents choices to the user.	Friendly names are best implemented indirectly by having any views call into the Spring message translation API, which supports some degree of I18N automatically. There is no UI currently to actually offer choices to the user, but this can be implemented as a pseudo-flow itself because flows can signal that a different flow should be run next.	This all hinges on whether we keep the MCB's declarative approach to configuration. See below. (DW)
9	Configuration of whether the user is allowed to switch principals in the middle of a session.	V3 will not support switching back and forth (this is something browsers do for you now, via private modes), but V3 will automatically detect a switch and destroy the old session if a switch occurs, creating consistent behavior. The result of a switch is to ignore it and proceed with a new session by default, or can be toggled to trigger an error either locally or via a SAML response.	We need to put some thought into this, as my understanding of how v3 works would break our reliance on initial contexts to support second-factor-only devices like Duo. Perhaps those authentication methods could fail if the principle seems to change? (DW)
10	Compatibility of existing MCB authentication submodules.	(We haven't discussed this. Is it possible to define a v3 flow that will invoke an MCB submodule? Is there guidance we should give to people developing submodules in v2? Could we enable v3 flows for v2 MCB?)	What submodules have been implemented? Perhaps easier to provide v3 implementations for them? (DW)
11	Compatible behavior with the MCB, as described in Assurance Enhancements for the Shibboleth Identity Provider (19 April 2013) and the MCB testing User Stories.	We should re-do the acceptance tests we did for the MCB (as outlined in User Stories).	Anyone willing to spend some time configuring our test stories in v3? (DW)
12	Ability for user to choose among multiple contexts, when multiple contexts will satisfy the SP's request.	Some campuses turn this off, due to user confusion, although some use it.	A hook is available. This can be implemented with a webflow. (DW)

Some Thoughts about Configuration

The MCB uses a declarative configuration to describe a site's authentication contexts, what they satisfy, etc. Shib v3 requires the IdP admin to configure/program webflows. Personally, I think a major attraction of the MCB has been that it doesn't require programming (and that webflows are a form of programming), but (frankly) this is only one area where Shib configuration requires a fairly steep learning curve for the admin. As Keith Wessel said, "...will the rest of IDP V3 be encouraging the use of web flows to do anything out of the ordinary? If so, and if an IDP operator is expected to learn webflows, moving MCB configuration to webflows might be a good thing. Consistency is a good thing."

Should we assume that IdP admins who can will code their own webflows, and those who cannot need more help, anyway? Admin expertise is an underlying thread in the Alternative IdP Working Group's report. Maybe configuration of contexts and web flows should become a feature of something like the IdP-Installer from Sweden's SWAMID and Canada's Canadian Access Federation.