You can configure providers in an order of preference enabling an authentication cascade where each provider is sequentially queried until the user is logged in or fails to be authenticated. You want to set provider order to use for failover if one of the providers' sources is broken. For example, if you have three LDAP Providers and the Default Provider is Active, the authentication framework queries the first provider, and if the user is not found, queries each provider until the user is found and authentication succeeds or fails. If the user is not found in any provider, the authentication fails.

Setting the provider order

Use the following steps to set the Provider Order.

  1. On the Administrator Panel, in the Building Blocks section, select Authentication.
  2. On the Authentication page, select Provider Order.
  3. Using the drag-and-drop function, press and drag the providers in descending order, from first to last, or use the Keyboard Accessible Reordering tool to make order adjustments.
  4. Optionally, set Continue on error (see below "What is Continue on error?") as Yes. The default is No. This option indicates whether subsequent providers should be processed if a previous one fails due to an error. This option is global to the provider chain.

    Continue on error is only applicable if there is more than one Active provider in the list.

You can base Authentication Providers on two Authentication Mode types: REDIRECT and USER_PASS.

  1. REDIRECT type providers, such as CAS and Shibboleth, hand off authentication to the remote authentication source. These are not listed in the Provider Order as they are considered the authoritative source for authentication and handle their own authentication failures.
  2. USER_PASS type providers, such as Learn Default and LDAP, query the authentication source that returns one of four states. This allows for provider chaining.
  • Login succeeded.
  • User not found (framework tries the next provider).
  • User found but password invalid (framework aborts the login).
  • Something failed (framework only continues if Continue on Error is set).

What is continue on error?

When chaining together authentication providers it is possible to set whether the failure of a previous provider to authenticate a user should force the next authentication provider to attempt authentication. An understanding of the possible error conditions and resulting outcomes is useful for triaging login problems.

It is not possible to provide a comprehensive list of potential failure causes within an authentication architecture, but they can be classified in three groups - 1) Service Availability: failures which are the result of the authentication provider designated service being unavailable; 2) Authentication Service: the user not being found in the authentication provider designated service or an incorrect user password; 3) Lack of Blackboard Learn account.

Continue on error examples that will invoke the next active authentication provider:

Service availability and user not being found in the designated provider's name directory will result in continuing to the next authentication provider.

  • Connection error to the authentication provider fails. For example: Learn may not be able to contact the configured LDAP server.
  • Username not found in the authentication providers name directory. For example: user is not found in the configured LDAP directory.
Continue on error authentication failure examples that will not invoke the next active authentication provider:

Authentication provider discovery of the user, but the provision of an invalid password or (if successful password) the found user not having a Blackboard Learn user account will result in not continuing to the next authentication provider.

  • Connection to the authentication provider and user authentication is successful, but username not found in Blackboard. For example: the user is successfully authenticated via LDAP but does not have a Blackboard Learn user account.
  • Connection to the authentication provider is successful and the user is found, but the authentication provider was given an incorrect password, thus not authenticating the user. The user may or may not have a Blackboard Learn user account. For example: the user enters a correct username but invalid password for their LDAP account - LDAP finds the user, but cannot authenticate.