Date: Fri, 29 Mar 2024 13:34:42 +0000 (UTC) Message-ID: <1375619417.8031.1711719282242@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8030_339530081.1711719282240" ------=_Part_8030_339530081.1711719282240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Multi-Context Broker (MCB) was released in February of 2014 to impro= ve support for multi-factor authentication and assurance profiles in versio= n 2.x of the Shibboleth IdP. MCB functionality is also in the more re= cent Shibboleth IdP version 3.x.
Please see MCB for IdPv3
The focus of these pages is on the Multi-Context Broker (MCB) software f= or Shibboleth version 2.x. Please see Orchestrating Multiple= Authentication Methods and Contexts - The Multi-Context Broker (MCB) f= or information about implementing MCB functionality in Shibboleth IdP versi= on 3.x.
The Multi-Context Broker (MCB) is an extension to the Shibboleth IdP tha= t improves Shibboleth's handling of multiple authentication methods, includ= ing multi-factor authentication, as well as multiple authentication context= s and assurance profiles. This document contains information about the MCB,= what it can be used for, and how it is installed and configured.
For a quick overview of the MCB and what it does, please see the slides = from the April 30, 2014 IAM Online on the Multi-Con= text Broker, or The M= ulti-Context Broker, presented by David Walker and David Langenberg at = Identity Week 2013. The code is available from the MCB page on the Shibboleth wiki.
Read on for more detailed information.
Dick and the Two Factors
Dick's campus Identity Provider (IdP) supports two forms of authenticati= on, one requires Dick to enter a user name and password, and the other also= requires Dick to prove he is in possession of his cell phone. Some Service= Providers (SP) require user name and password, and some also require the c= ell phone. The campus has decided, however, that the cell phone metho= d can always be used, even when only user name and password is requested by= the SP. When Dick browses to an SP requiring user name and password,= he is prompted accordingly, and he is no longer prompted for the rest of h= is session, unless he browses to an SP requiring the cell phone method.&nbs= p; In that case, his cell phone alerts him for confirmation, and he then is= no longer prompted for any SP during the rest of his session.
In order to provide Dick with choices to protect his online identity, Di= ck's campus allows him to opt out of ever authenticating without using the = cell phone method. After choosing that option, he is always prompted = to use the cell phone method, even when it is not required by the services = he uses.
Assuring Jane
Jane uses her web browser to access a Service Provider (SP) that require= s the InCommon Bronze assurance profile. The SP redirects her to her = campus Identity Provider (IdP), the MCB verifies she is certified for the B= ronze profile, and she is presented with a list of authentication methods i= t provides that will satisfy the requirements of InCommon Bronze. Jan= e chooses one of those methods and authenticates. Jane's IdP returns = the Bronze assurance qualifier to the SP. As Jane browses to other Br= onze SPs during her current session, her IdP provides the Bronze assurance = qualifier to those SPs without requiring additional interaction for authent= ication.
During her session, Jane browses to a Service Provider that requires the= InCommon Silver assurance profile. At Jane's campus, the Silver assu= rance profile requires a different authentication method than Bronze, so (a= fter verification that Jane is certified for the Silver profile) Jane is pr= ompted for Silver authentication.
This is only a little of what the Multi-Context Broker 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 ses= sion, as the Silver profile satisfies all the requirements of the Bronze pr= ofile. We'll have to dive a little deeper, though, to describe = this.
The Multi-Context Broker enhances the Shibboleth IdP=E2=80=99s ability t= o orchestrate among multiple Authentication Contexts, including those requi= ring multi-factor authentication. To do this, it considers informatio= n 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), there are three option= s:
This section briefly describes a few potential uses for the Multi-Contex= t Broker, indicating what would need to be configured to implement them. Fo= r detailed configuration information, please see the MCB page on the Shibboleth wiki.
Users are presented with the authentication method, either password or m= ulti-factor, that matches the requested Context. All users can use ei= ther method.
Authentication methods are controlled within the IdMS. SPs request
InCommon Bronze and Silver share a common username/password authenticati= on method. Users authenticate once per session with the single Authenticati= on Method, and SPs receive the requested Context (or failure), based on use= r certifications.
There are two authentication methods, one for Bronze, and one for Silver= . Users who have previously authenticated for BronzeContext will need to reauthenticate (with multi-factor) for a subsequent = SilverContext request, but users who have previously authenticated= for SilverContext will not need to reauthenticate for a s= ubsequent BronzeContext request.
The MCB supports all of the functionality described in this document, an= d the following authentication methods are supported:
The following are potential areas for future development:
During 2012, the InCommon Assurance Program explored implementation issu=
es 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=
=E2=80=99s SAML2 Web SSO Profile for requesting Authentication Contexts (
While testing, campus implementers identified the following issues, as o= f version 2.4 of the Shibboleth IdP:
In January of 2013, InCommon convened a group section to share their tes= ting experiences to date and assist in the development of a requirements do= cument for an initial set of enhancements to the Shibboleth IdP to address = these issues that could be 1) delivered to the Shibboleth Consortium for co= nsideration in future IdP release and 2) used as a basis for an RFP, jointl= y funded by InCommon and the NSTIC-funded Scalable Privacy Project, to deve= lop 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 t= he supporting identity management and authentication systems, suggests a ce= rtain level of configurability and flexibility in how the Shibboleth IdP su= pports the bullets above. To support the Silver Identity Assurance profile,= an organization may determine that bringing its password infrastructure in= to compliance is a viable option, where another may layer on a multi-factor= solution and bypass the complexity and scope of the current password infra= structure. The solution must be able to manage the use of multiple authenti= cation systems, contexts in which they are required, and the user=E2=80=99s= ability to control their authentication method when multiple options exist= .
Under the guidance of Ann West and David Walker, the RFP was issued in J= uly, 2013, based on the specifications in Assurance Enhancements for the Shibboleth Identity Pro= vider (19 April 2013), was awarded to Paul Hethmon, and implementation = began. Acceptance testing for the MCB completed in January, 2014, and the M= CB 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.