...
The Multi-Context Broker Model is a useful way to think about the Shibboleth IdP's orchestration among multiple authentication methods in support of multi-factor 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 the MCB page on the Shibboleth wiki. [This link will need to change to the IdPv3 wiki space.]
...
The Multi-Context Broker Model helps to guide configuration of the Shibboleth IdP’s ability to orchestrate among multiple Authentication Contexts, including those requiring multi-factor multifactor authentication. To do this, it considers information from multiple sources:
...
Users are presented with the authentication method, either password or multi-factormultifactor, that matches the requested Context. All users can use either method.
- Two Authentication Contexts
- PasswordContext with some username/password Authentication Method
- MFAContext with some multi-factor multifactor Authentication Method
- All users are given PasswordContext and MFAContext.
- SPs requiring MFA request MFAContext.
- SPs requiring username/password request PasswordContext
...
Authentication methods are controlled within the IdMS. SPs request PasswordContext (or do not request an Authentication Context). Users are presented for username/password or MFA, depending on their certifications within the IdMS. This is a method for providing an "user opt-in" requirement for multi-factor multifactor authentication, similar to that provided by Google and other cloud providers.
- Two Authentication Contexts
- PasswordContext with some username/password Authentication Method
- MFAContext with some multi-factor multifactor Authentication Method
- MFAContext satisfies PasswordContext
- Most users given PasswordContext
- Users allowed to use MFA given MFAContext and PasswordContext
- They may be presented with a choice of authentication methods
- Users required to use MFA are given only MFAContext
...
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-factormultifactor) for a subsequent SilverContext request, but users who have previously authenticated for SilverContext will not need to reauthenticate for a subsequent BronzeContext request.
- Two Authentication Contexts
- BronzeContext with some username/password Authentication Method
- SilverContext with some multi-factor multifactor Authentication Method
- SilverContext satisfies BronzeContext
- Users are certified for BronzeContext and/or SilverContext, based on identity proofing, registration, etc. These are stored in the IdMS.
...
- If a user used her password to log in as a Bronze authnContext, she had to use the same password to re-login for Silver. Shibboleth does not know that the same authentication method is used for both Bronze and Silver, forcing re-authentication, even when a previous context’s authentication would suffice.
- If a user logs in with his password, accesses a Silver-service, but has forgotten his hardware token required to assert the Silver Authentication Context, he cannot decide to accept a lower level of service by telling the IdP to go ahead and assert Bronze on his behalf. The login handler doesn’t support such multi-factor multifactor use cases well.
- If an SP passed a list of Authentication Contexts (e.g., [Silver, Bronze, unspecified]) with the intent of having the IdP provide the highest possible Context for the user, the IdP would not process the list in a prioritized fashion, resulting in a Bronze Context sent one time, Silver another, and unspecified as well.
...
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 multi-factor 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.
...