The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

DRAFT - Multi-Context Broker Functionality for Shibboleth v3 - DRAFT

Owned by Former user (Deleted)
Last updated: Apr 20, 2015 by dwalker@internet2.edu

The Multi-Context Broker plugin for Shibboleth v2 has been a great success by providing an implementation platform for early adopters of multi-factor authentication and the InCommon Assurance Program, about a year ahead of the release of Shibboleth v3.  Even more important:

  • It has raised the awareness of its capabilities throughout the community, putting those capabilities into the planning horizon of many universities and service providers ranging from CILogon to WorkDay.
  • It has educated the implementation of these capabilities in Shibboleth v3.

As we knew at the start, however, the MCB would not be directly transferable to Shibboleth v3.  It was known that the Shibboleth v2 interfaces used by the MCB would be changing, but it was not known at the time what those new interfaces would be.  We knew that additional work would be required to continue MCB functionality for Shibboleth v3.

Other than a few issues listed below, the Shibboleth v3 IdP can provide the MCB functionality of orchestrating among multiple authentication contexts to support assurance profiles and strong authentication.  Shibboleth v3 does, however, raise the bar for IdP system administrators by requiring knowledge of Spring Web Flow technology to customize the IdP.  This has the potential to slow the deployment of strong authentication technologies and assurance in Shibboleth, but that decision was made by the Shibboleth project long ago, and we recognize that there are multiple positive benefits of using Spring Web Flow.

Also, this is not the only aspect of Shibboleth that calls for tools and other forms of assistance for system administrators, as highlighted by the Alternative IdPs Working Group's "Identity Provider Strategies for Common Campus Environments," the next round of federation participants will need more help.  This will also be true for existing federation participants as they deploy assurance and strong authentication.

We believe that bringing the MCB's simpler configuration paradigm to Shibboleth v3 is not the best use of resources.  Rather, resources should be put into tools, education, and training to help system administrators configure multiple authentication contexts and methods in Shibboleth v3, without additional plugins like the MCB.  Further, since this is not the only area of Shibboleth administration requiring assistance, the MCB administration issues should be part of a larger effort for Shibboleth administrators, even if the MCB issues are addressed first.

Resolving Specific Issues

A gap analysis between the MCB and Shibboleth v3 is available on the Shibboleth wiki.  Those gaps that are not explicitly resolve in the gap analysis are highlighted here.

  • 5 - Ability to configure "initial" authentication contexts.  We believe there is actually no gap here, subject to testing, as described below.
  • 6 - Configuration option to specify behavior when a user has no context certifications.  This is an edge case; in general, we would expect IAM systems to ensure that all users do have at least one certification.  As long as v3's behavior is documented, we believe no further work is needed here.
  • 7 - Configuration of the maximum number of authentication failures.  We have determined that this MCB feature is not needed.
  • 8 - Configuration of friendly names for authentication methods.  This is not needed, as friendly names would be part of the UI coded for the web flow.
  • 9 - Configuration of whether the user is allowed to switch principals in the middle of a session.  We have determined this is not needed.  SAML allows users to switch principals, so it's best to stick with the standard.
  • 10 - Compatibility of existing MCB authentication submodules.  Pending testing, we believe existing MCB submodules can be used in Spring Web Flows.
  • 12 - Ability for user to choose among multiple contexts, when multiple contexts are feasible.  While presenting users with choice can cause confusion, there are use cases where this is appropriate.  A hook for this is provided in Shib v3, but no web flow has been created as yet to make use of the hook.

In addition to closing the remaining gaps, we recommend:

  • Test Shibboleth v3 against the User Stories that were used to test the MCB.
  • Designate a repository for community-contributed example web flows and configuration snippets.

Next Steps

Assuming concurrence with the general strategy among the MCB project group, the Shibboleth trainers, InCommon, and the Shibboleth project we will propose a plan for testing existing MCB submodules and the User Stories against Shibboleth v3.  (This testing, of course, may require Shibboleth work to resolve issues discovered.  We should be prepared to contribute to that effort.)  We will also designate a repository for example / template work flows and configurations, and seed it with those used to test the User Stories.