...
- It compares the SPs requested Authentication Contexts against the the Contexts the user is certified to use plus any Contexts that are satisfied by the user's certified Contexts to determine the Contexts that can be used for this transaction.
- It presents the Authentication Methods associated with the Authentication Contexts that can be used for this transaction to the user. If the SP requested multiple Contexts, the Methods are presented in the priority order of their requested Contexts. If an Authentication Method can be used for multiple Contexts, it is presented only once for the highest-priority Context.
- The user selects one of the presented Authentication Methods (assuming there is more than one) and authenticates. Upon successful authentication, the MCB returns the SP-requested Authentication Context that has been satisfied. (Note, the MCB and Shibboleth maintain session state to enable single sign-on. Once the user has authenticated with a particular Authentication Method, that Method will not require further user interaction for the rest of the session, unless the SAML "force authentication" option is specified.)
Note that the process described above assume 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 options:
...
During 2012, the InCommon Assurance Program explored implementation issues of assurance, most notably with CI LogonCILogon, 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). CI LogonCILogon, run by NCSA, has more flexibility in its requirements.
...
In addition, the diversity in HIgher Education 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 multi-factor 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.
The RFP was issues issued in July, 2013, based on the specifications in Assurance Enhancements for the Shibboleth Identity Provider (19 April 2013)|../../../../../../../../../../download/attachments/46500870/AssuranceReqShibIdP-19Apr2013.pdf?version=1&modificationDate=1391732481566\, was awarded and implementation began. Acceptance testing for the MCB completed in January, 2014, and the MCB was released in February, 2014.