DRAFT - The Multi-Context Broker - DRAFT

The Multi-Context Broker (MCB) is an extension to Shibboleth 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.

For a quick overview of the MCB and what it does, please see The Multi-Context Broker, presented by David Walker and David Langenberg at Identity Week 2013, as well as [this demonstration] [TBD].  Read on for more detailed information.

History

During 2012, the InCommon Assurance Program explored implementation issues of assurance, most notably with CI Logon, 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 Logon, run by NCSA, has more flexibility in its requirements.

While testing, campus implementers identified the following issues, as of version 2.4 of the Shibboleth IdP:

• 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.

• 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 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 to develop a short term solution for campuses interested in implementing assurance over-the-wire.

In summary, the testing group saw two primary SP use cases:

• The SP requests a specific Authentication Context, like Silver.

• 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 RFP was issues in July, 2013, based on the specifications in Assurance Enhancements for the Shibboleth Identity Provider (19 April 2013), was awarded and implementation began. Acceptance testing for the MCB completed in January, 2014, and the MCB was released in February, 2014.

Defining Some Terms

• Authentication Method. A method for authenticating the identity of the current user.  Examples are username/password, X.509 client certificates, one-time password devices, etc. In the context of the MCB and Shibboleth, this is a specific instance of such a method.  For example, the UC Irvine's UCInetID system (which is based on Kerberos software) is an Authentication Method, whereas the generic Kerberos software is not.  (In this document, "Authentication Method" is often shortened to "Method" for brevity.)
• Authentication Context. The context of the authentication event that results in a SAML assertion sent from the IdP to an SP.  Authentication Context is comprised of an Authentication Method, plus any other relevant criteria, such as the identity proofing and registration processes used to issue credentials to the current user.  In SAML, only the name of an Authentication Context is sent between IdPs and SPs; the Authentication Method and other criteria associated with that name are documented separately.  It should be noted that it is often the case the multiple Authentication Contexts form a hierarchy, in the sense that one Authentication Context's criteria may satisfy the criteria of another Authentication Context.  For example, InCommon Silver satisfies the criteria for InCommon Bronze. (In this document "Authentication Context" is often shortened to "Context" for brevity.)
• Assurance Profile. Criteria related to the trustworthiness of SAML assertions, such as InCommon Bronze and Silver.  Assurance Profiles are represented in SAML as Authentication Contexts.

What Does the Multi-Context Broker Do?

The Multi-Context Broker enhances the Shibboleth IdP’s ability to orchestrate among multiple Authentication Contexts, including those requiring multi-factor authentication.  To do this, it considers information from multiple sources:

• The Authentication Contexts requested by a Service Provider (SP), in priority order,
• The Authentication Contexts that the current user is certified to use, stored in the Identity Management System, and
• The hierarchy of Authentication Contexts, representing where one context satisfies the requirements of another.

When the MCB receives a request from an SP:

1. 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.
2. 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.
3. 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 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:

• All Authentication Methods known to the MCB are presented to the user.
• All Authentication Methods known to the MCB that satisfy the SP's request are presented to the user.
• The user is presented with a configured Authentication Method to determine their identity, then the process described above is invoked.

Example Uses for the Multi-Context Broker

Authentication Method Selected by SP Request

• Two Authentication Contexts
  • PasswordContext with some username/password Authentication Method
  • MFAContext with some multi-factor Authentication Method
• SPs requiring MFA request MFAContext.
• SPs requiring username/password request PasswordContext
• Users are presented with the authentication method that matches the requested Context

Authentication Method Selected by User Certification

• Two Authentication Contexts
  • PasswordContext with some username/password Authentication Method
  • MFAContext with some multi-factor 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 (perhaps by their choice) are given only MFAContext
• SPs request PasswordContext (or do not request an Authentication Context).  Users are presented for username/password or MFA, depending on their certifications.

InCommon Bronze and Silver with One Authentication Method

• Two Authentication Contexts
  • BronzeContext with the one username/password Authentication Method
  • SilverContext with the one username/password Authentication Method
  • SilverContext satisfies BronzeContext
• Users are certified for BronzeContext and/or SilverContext, based on identity proofing, registration, etc. This is stored in the IdMS.
• Users authenticate once per session for the single Authentication Method.  SPs receive the requested Context (or failure), based on user certifications.

InCommon Bronze and Silver with Two Authentication Methods

• 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.
• Users who have previously authenticated for BronzeContext will need to reauthenticate (with multi-factor) for a subsequent SilverContext request.
• Users who have previously authenticated for SilverContext will not need to reauthenticate for a subsequent BronzeContext request.

Sample Configurations

• Configuration examples from acceptance testers

Where Do I Get the Multi-Context Broker?  How Do I Report Bugs?  Where is the Source?

• The MCB page on the Shibboleth wiki provides links to the MCB plugin and detailed documentation for installation and configuration.
• The source files for the MCB are available at https://github.com/Internet2/Shibboleth-Multi-Context-Broker. Issues will be tracked here, as well.
• Please ask questions and report bugs to users@shibboleth.net.

Current State of the Implementation

The MCB supports all of the functionality described in this document, and the following authentication methods are supported:

• Authentication methods supported by JAAS, such as username / password.
• Authentication methods supported by Shibboleth's "REMOTE_USER" method, such as X.509 client certificates.

The following are potential areas for future development:

• A slicker user interface with fewer page transitions.
• Additional Authentication Methods