The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

BlackboardShibProposal

Owned by Former user (Deleted)
Last updated: Jan 25, 2009Version comment
5 min read

Proposal for Blackboard & Shibboleth Integration

Summary

Many schools desire to use Shibboleth authentication and attribute data in conjunction with their Blackboard learning system implementations. For many years, Blackboard has shipped an "unofficial" Shibboleth authentication module with their product. It provides a limited capability to use Shibboleth with Blackboard, by extending their existing web server delegation (REMOTE_USER-oriented) login module to examine a different request header supplied by an instance of the Shibboleth Service Provider (SP) sitting in front of the Blackboard login broker endpoint. While it is functional, many people express more advanced needs than basic authentication, especially due to the complexities of non-local users in a federated environment.

This proposal is for a new Blackboard Shibboleth module to be developed to meet some or all of those needs. Design goals would be to provide a greater degree of configurability, flexibility and extensibility/plugability than the current module, especially in the areas of account creation and provisioning.

Several use cases are considered to be in-scope for this work:

  • Users - both local and non-local - are created and provisioned within Blackboard by an existing out-of-band process, such as the Snapshot batch tool or using the Event Driven API's. The module then handles authentication only.
  • Local users are created and provisioned out-of-band per existing processes, but federated non-local users are created and/or provisioned at the time of login by the module.
  • All users are created and/or provisioned by the module.

Some specific use cases with respect to account creation and provisioning:

  • New users might be created based on Shibboleth-supplied attribute data, but not provisioned in any courses. Instructors or Blackboard admins would add the user to courses manually after the user's first login.
  • New users might be created and provisioned in a course based on information supplied by their home Identity Provider (IdP), via for example eduCourse or eduPersonEntitlement attribute data.
  • New users might be both created and provisioned in courses based on Shibboleth attribute data, but only after course enrollment is verified against an existing local system of record, such as the campus student information system. This verification might entail a call to a service API exposed by the campus system, which is capable of verifying or supplying enrollment data in real-time.

Overview

The new module would still assume the use of the native Shibboleth SP, configured in the web server used by Blackboard. Attributes supplied by the Shibboleth SP via request headers or environment variables would be used to supply user-specific information to the module as appropriate, and as desired by the deployment.

The implementation would be in Java, as required by the standard Blackboard authentication API. The module would implement the blackboard.platform.security.authentication.HttpAuthModule interface.

Authentication

Authentication would entail the module consuming the value of a specific Shibboleth-supplied username value. In the current module, this is hardcoded to a specific attribute name. In the new proposal, a configuration option would allow choice of a particular Shibboleth-supplied attribute value.

In the federated scenario, usernames are often supplied by Shibboleth to consuming applications in a form that includes a security domain qualifier, e.g. 'smithj@example.org', such as recommended by the eduPerson specification's eduPersonPrincipalName. Use of this scoped principal name within Blackboard directly as the Blackboard username is a possibility. However many or most existing Blackboard deployments utilize unscoped usernames for existing local users.

To allow both existing local users and new federated, non-local users within a given Blackboard deployment, an option would be supplied to map the Shibboleth-supplied principal name to the username that will be used by Blackboard. A plugin class which implements a defined interface could be supplied in the Blackboard config which performs the translation according to an institution's local requirements.

Given the wide use of eduPersonPrincipalName, a default implementation of this plugin interface would be supplied that accepts as a configuration option a list of security domain scopes that are to be treated as local. If a given username value matches one of these scopes, the Blackboard username returned would correspond to the local identifier portion of the scoped principal name. If it does not match, the unmodified scoped principal name would be returned.

User Account Existence

A user authenticated by the module may or may not already exist within the Blackboard system. For users determined to not yet exist, several options could be supplied, similar to those offered by other Blackboard authentication modules:

  • Deny - The user is denied access to the Blackboard system.
  • Create - The user is created within the Blackboard systems based on Shibboleth-supplied attribute data.
  • Provision - The user is both created within Blackboard (if necessary) and provisioned into courses based on Shibboleth-supplied attribute data.

An additional possibility (to be investigated for utility and feasibility) is that this option could be supplied separately for local vs. non-local/federated users, to allow them to be handled differently.

Account Creation

Authenticated users for whom account creation is determined to be necessary and allowed could have accounts created at runtime using the Blackboard API's. Shibboleth-supplied attribute data would be used to needed to supply user-specific information, such as first name, last name, and email address.

A plugin class which implements a defined interface could be supplied in the Blackboard config which performs account creation. The extensible plugin approach allows institutions to customize the account creation process to fit their needs.

A default and basic implementation of the plugin interface would be supplied that handles the common use cases. Possible options include:

  • Shibboleth-supplied attribute names to consume for each required data element.
  • Whether the absence of an attribute value is considered an error, or a default value can be supplied.
  • Default values for particular attribute data values, if appropriate.

Provisioning

A user authenticated by the module may optionally need to be provisioned into courses at runtime, again using the existing Blackboard API's. Shibboleth-supplied attribute data could be used to supply course enrollment info.

A plugin class which implements a defined interface could be supplied in the Blackboard config which performs account provisioning. The extensible plugin approach allows institutions to customize account provisioning to fit their needs.

It is expected that the needs and requirements for provisioning may vary widely based on local policies and requirements. It may or may not be possible to come up with a default provisioning plugin implementation that is general enough to satisfy a wide audience.

Possible options for provisioning modules include:

  • Shibboleth-supplied attribute names to consume for enrollment data.
  • Translation or mapping of attribute data in the form asserted by the IdP (e.g. URI syntax via eduCourse) into the corresponding Blackboard course ID form necessary for course provisioning via the Blackboard API's.

Some questions and issues to consider regarding provisioning:

  • Would local policy allow enrollments to be provisioned solely on the basis of information asserted by a user's home IdP?
  • Would enrollments need to be verified against local systems of record, such as based on registrar data or the Student Information System?
  • Need for agreement between Identity Providers and the Blackboard hosting institution on the exact manner in which courses are represented and asserted by the IdP. Is there a need to support different representations on IdP-specific basis?
  • Are users auto-deprovisioned in any manner, such as when the attribute data states that they are no longer in a particular course? (could be dangerous...) Or after a certain period time?

Additional Issues and Questions

  • Is there a need to support both Shibboleth authentication and other mechanisms (e.g. LDAP) simultaneously?
    • Possibly differentiated along the lines of local users vs. non-local/federated users
  • Some Blackboard components are not web based and assume/require the use of of a username and password. Options for handling for federated users?