The Multi-Context Broker Model is a useful way to think about the Shibboleth IdP's orchestration among multiple authentication methods in support of multifactor authentication, as well as multiple authentication contexts and assurance profiles. This document is a brief tutorial about the MCB Model and how it can be used. Recipes for configuring the MCB Model in IdPv3 are available from Orchestrating Multiple Authentication Methods and Contexts - The Multi-Context Broker (MCB).
This is only a little of what the Multi-Context Broker Model can do. For example, if the first SP Jane used required the Silver profile, she would not be prompted to authenticate for later Bronze SPs during the current session, as the Silver profile satisfies all the requirements of the Bronze profile. We'll have to dive a little deeper, though, to describe this.
The Multi-Context Broker Model helps to guide configuration of the Shibboleth IdP’s ability to orchestrate among multiple Authentication Contexts, including those requiring multifactor authentication. To do this, it considers information from multiple sources:
When the MCB receives a request from an SP:
Note that the process described above assumes knowledge of the identity of the current user. When the current user is not already known to the MCB (i.e., this is the start of a new session), the IdP can present the user with a configured Authentication Method to determine their identity, then the process described above is invoked.
This section briefly describes a few potential uses for the Multi-Context Broker, indicating what would need to be configured to implement them. For detailed configuration information, please see Orchestrating Multiple Authentication Methods and Contexts - The Multi-Context Broker (MCB).
Users are presented with the authentication method, either password or multifactor, that matches the requested Context. All users can use either method.
If an SP does not explicitly specify a RequestedAuthnContext, then a default can be identified in relying party configuration. If that default is for MFAContext, then that would have the same effect as the SP requesting MFAContext. See Configuring the IdP for the Multi-Context Broker Model for more information.
Authentication methods are controlled within the IdMS. SPs request PasswordContext (or do not request an Authentication Context). Users are prompted for username/password or MFA, depending on their certifications within the IdMS. This is a method for requiring certain users to use MFA, or for providing "user opt-in" similar to that provided by Google and other cloud providers.
InCommon Bronze and Silver share a common username/password authentication method. Users authenticate once per session with the single Authentication Method, and SPs receive the requested Context (or failure), based on user certifications.
There are two authentication methods, one for Bronze, and one for Silver. Users who have previously authenticated for BronzeContext will need to re-authenticate for a subsequent SilverContext request, but users who have previously authenticated for SilverContext will not need to re-authenticate for a subsequent BronzeContext request.
Second factor only technologies like U2F and Duo are not full-fledged Authentication Methods, as described in this document. The MCB Model, and IdPv3, consider an Authentication Method as something that tells you who the current user is. Second factor only technologies do not do this; you tell them who you think the current user is, and they tell you if they agree with that (increasing your confidence in who the current user is).
For this reason, the user must have been authenticated with a first factor before a second factor method can succeed. For now, this requires configuration of an initial authentication method, as described in Configuring the IdP for the Multi-Context Broker Model and/or custom authentication flow scripting. The Shibboleth community, however, is working to enhance IdPv3's ability to accommodate second factor only technologies.
There are two authentication methods, one for Bronze, and one for Silver. All users are required to authenticate for BronzeContext at the beginning of their session with the IdP. Users will need to provide their second factor for a subsequent SilverContext request, but they will not need to re-authenticate for a subsequent BronzeContext request.
During 2012, the InCommon Assurance Program explored implementation issues of assurance, most notably with CILogon, National Institutions of Health and the Department of Education. The latter two organizations are required to follow the Federal Identity Credential and Access Management committee’s SAML2 Web SSO Profile for requesting Authentication Contexts (e.g., assurance profiles). CILogon, run by NCSA, has more flexibility in its requirements.
While testing, campus implementers identified the following issues, as of version 2.4 of the Shibboleth IdP:
In January of 2013, InCommon convened a group section to share their testing experiences to date and assist in the development of a requirements document for an initial set of enhancements to the Shibboleth IdP to address these issues that could be 1) delivered to the Shibboleth Consortium for consideration in future IdP release and 2) used as a basis for an RFP, jointly funded by InCommon and the NSTIC-funded Scalable Privacy Project, to develop a short term solution for campuses interested in implementing assurance over-the-wire.
In summary, the testing group saw two primary SP use cases:
In addition, the diversity in hIgher education IdP implementations and the supporting identity management and authentication systems, suggests a certain level of configurability and flexibility in how the Shibboleth IdP supports the bullets above. To support the Silver Identity Assurance profile, an organization may determine that bringing its password infrastructure into compliance is a viable option, where another may layer on a multifactor solution and bypass the complexity and scope of the current password infrastructure. The solution must be able to manage the use of multiple authentication systems, contexts in which they are required, and the user’s ability to control their authentication method when multiple options exist.
Under the guidance of Ann West and David Walker, the RFP was issued in July, 2013, based on the specifications in Assurance Enhancements for the Shibboleth Identity Provider (19 April 2013), was awarded to Paul Hethmon, and implementation began. Acceptance testing for the MCB completed in January, 2014, and the MCB was released in February, 2014. The acceptance testers were David Langenberg of the University of Chicago, Keith Wessel of the University of Illinois, and Mike Wiseman of the University of Toronto.
With the release of IdP Version 3 in late 2014, the MCB team's focus shifted form software development to documenting the MCB Model and how it can be configured in IdPv3.