Integrating Blackboard Connect with Shibboleth for institutional authentication of users and SSO

University of Alaska Identity & Access Management November 2012 University of Alaska has implemented central authentication and "single sign-on" (SSO) using ​Shibboleth. The following is a brief description of the steps taken by UA to have services from ​Blackboard Connect rely on our central authentication to log in users. This description does not attempt to be a general guide to either Shibboleth or Blackboard Connect. It is focused merely on the specific steps to integrate vendor-hosted Blackboard Connect services with a working campus-based Shibboleth Identity Provider (IdP). These steps are a little different than a prototypical integration because
(1) Blackboard CONNECT entity id's depend on an X509 certificate the customer uploads to the hosted service,
(2) Blackboard CONNECT does not as of this writing participate in the ​InCommon federation, requiring manual addition of metadata and certificates, and most important
(3) Blackboard CONNECT uses "unsolicited" or "IdP-initiated" SSO, which entails a work flow that differs from the norm.

Step 1: (1) Determine the entity id for BBC service(s)

The Blackboard Connect administrative interface provides a setting to configure the service for Single Sign-On (SSO). You will of course need to have been provided administrative-level access and credentials by Blackboard Connect. You will also need to upload your IdP certificate. You need to do this step first because later steps will need the custom entity id generated in this process.

1.1 Have a copy of your IdP certificate ready to upload

1.2 Login to the admin interface ​https://www.blackboardconnect.com/signin/default.aspx# with credentials provided by Blackboard Connect.

1.3 As documented in Connect SSO Implementation Manual, open the ADMIN tab, Choose "Settings" then "Single Sign On Configuration Setup"

to bring up the dialog to enable SSO and upload your certificate in this dialog:

1.4 Upload your IdP's X509 certificate using the controls in the web form.

1.5 Determine the unique entity id ("url") for your SSO-enabled service(s). [BBC will have to describe just how you find that url in the interface!] The entity id for the staging (testing) service will have a format like: ​https://ssostg.blackboardconnect.com/SAML/Connect/B46C75BF139144349190F775C38F05A9 The entity id for your production portal for end users will have a format like: ​https://sso.blackboardconnect.com/SAML/Portal/E0D069C2563D4D63A14CBB95D6845C25 The entity id for your production instance of Connect (at UA we call this the "Sender Portal" available only to those who can trigger alerts) will have a format like ​https://sso.blackboardconnect.com/SAML/Connect/9F95200F70EB4E8F844320653CCD97A8 

(2) Configure your IdP for BBC service(s).

The Shibboleth IdP relies on several xml files for knowing whether and how to communicate with services to assert authentication and attributes for authenticated users. Metadata for service providers (SPs) in the InCommon federation can be consumed automatically, but BBC services are not in InCommon, so you must add metadata specifically for BBC. In addition, you will likely have to generate specific attributes for BBC (in attribute-resolver.xml) and set an appropriate release policy to send those attributes to BBC (in attribute-filter.xml).

(2.1) Add descriptors and certificates for BBC services into the metadata used by your IdP. Your IdP will be configured to consume metadata from one or more files. Add EntityDescriptor? elements - including the entityIDs from step 1 and a certificate for each of the BBC services to be integrated to one of these files (order in which EntityDescriptors? are listed or read is immaterial). As of this writing, the certificate itself is not actually used, so any certificate will do! Even though not actively used, a certificate must be present. The entityID must exactly match the entityID from step 1. example (a more complete example is in the appendix):