The Multi-Context Broker
...
Multi-Context Broker Model
The Multi-Context Broker
...
(MCB) was released in February of 2014 to improve support for multi-factor authentication and assurance profiles in version 2.x of the Shibboleth IdP. MCB functionality is also in the more recent Shibboleth IdP version 3.x.
| Warning | ||
|---|---|---|
| ||
The focus of these pages is on the Multi-Context Broker (MCB) software for Shibboleth version 2.x. Please see Orchestrating Multiple Authentication Methods and Contexts - The Multi-Context Broker (MCB) for information about implementing MCB functionality in Shibboleth IdP version 3.x. |
The Multi-Context Broker (MCB) is an extension to the Shibboleth IdP that improves Shibboleth's handling of multiple authentication methods, including multi-factor authentication, as well as multiple authentication contexts and assurance profiles. This document contains information about the MCB, what it can be used for, and how it is installed and configured.
Wiki Markup
Read on for more detailed information.
| Table of Contents |
|---|
...
|
...
|
A Couple of Short Stories
| Info | ||
|---|---|---|
| ||
Dick's campus Identity Provider (IdP) supports two forms of authentication, 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 cell phone. The campus has decided, however, that the cell phone method 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 his session, unless he browses to an SP requiring the cell phone method. 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. If the first SP he accesses requires the cell phone method, he will not be prompted again for the rest of the session, regardless of which SPs he uses. In order to provide Dick with choices to protect his online identity, Dick'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. |
...
- Two Authentication Contexts
- BronzeContext with some username/password Authentication Method
- SilverContext with some multi-factor 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.
Sample Configurations
- University of Chicago - Support for username/password, Duo Security, and InCommon Silver
- University of Toronto - Support for username/password and SafeNet eTokenPASS OTP
Where Do I Get the Multi-Context Broker? How Do I Report Bugs? Where is the Source?
...
- Authentication methods supported by JAAS, such as username / password.
- Authentication methods supported by Shibboleth's "REMOTE_USER" method, such as X.509 client certificates.
- Duo Security, via a contribution the University of Chicago
The following are potential areas for future development:
...
- 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 use cases well.unmigrated-wiki-markup
- 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 January of 2013, InCommon convened the a group described in the Acknowledgements 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.
...
- The SP requests a specific Authentication Context, like Silver.unmigrated-wiki-markup
- The SP requests one of a set of Authentication Contexts, in priority order (_e.g._, \ [Silver, Bronze\]), that are required for different levels of service. The IdP presents a choice of authentication methods that will satisfy the request and for which the user is eligible, and returns the selected Context to the SP upon successful authentication. The SP then tailors the service provided accordingly.
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 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 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.