Date: Fri, 29 Mar 2024 07:13:02 +0000 (UTC) Message-ID: <731185152.7597.1711696382614@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7596_192615974.1711696382614" ------=_Part_7596_192615974.1711696382614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Multi-Context Broker Model is a useful way to think about the Shibbo= leth IdP's orchestration among multiple authentication methods in support o= f multifactor authentication, as well as multiple authentication contexts a= nd assurance profiles. This document is a brief tutorial about the MCB Mode= l and how it can be used. Recipes for configuring the MCB Model in IdPv3 ar= e available from the MCB page on the Shi= bboleth wiki. [This link will need to change to the IdPv3 wiki sp= ace.]
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 Model can do.&nbs= p; 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 curre= nt session, as the Silver profile satisfies all the requirements of the Bro= nze profile. We'll have to dive a little deeper, though, to des= cribe this.
The Multi-Context Broker Model helps to guide configuration of the Shibb= oleth IdP=E2=80=99s ability to orchestrate among multiple Authentication Co= ntexts, including those requiring multifactor authentication. To do t= his, 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 th= e 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-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= ultifactor, that matches the requested Context. All users can use eit= her 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 multifactor) for a subsequent S= ilverContext request, but users who have previously authenticated = for SilverContext will not need to reauthenticate for a su= bsequent BronzeContext request.
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 multifactor = solution and bypass the complexity and scope of the current password infras= tructure. The solution must be able to manage the use of multiple authentic= ation 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 Prov= ider (19 April 2013), was awarded to Paul Hethmon, and implementation b= egan. Acceptance testing for the MCB completed in January, 2014, and the MC= B was released in February, 2014. The acceptance testers were David L= angenberg of the University of Chicago, Keith Wessel of the University of I= llinois, and Mike Wiseman of the University of Toronto.
With the release of IdP Version 3 in late 2014, the MCB team's focus shi= fted form software development to documenting the MCB Model and how it can = be configured in IdPv3.