Recently I completed work on adding single sign-on functionality to our Blackboard Learn environments by integrating the login with our CAS server. To understand how this works, you first need a basic understanding of the authentication architecture that was being used prior to adding CAS to the mix.

Our environment provides users with two primary methods of authenticating to services on our network. One method is via a username/password, where the username is some representation of the users name (usually the first part of their email address).   The other method is via a unique userid/pin, where the userid is a unique nine digit number.

Our Bb Learn environment has traditionally used the userid/pin credential set, whereas the CAS server is tied to the username/password credential set – so integrating the two provided a little less straightforward that it might otherwise have been.

Our users are imported to our Learn environment via XML imports from our SIS, using the IMS Enterprise 1.1 – Vista XML format. Both user identifiers are included in the XML that is exported from the SIS, but the challenge was always how to tell Blackboard that either method of user authentication would be acceptable. By adding CAS as an available authentication method, I didn’t want to – at the same time – invalidate the way that users had traditionally been able to login to the system.

The key to making authentication work both with the traditional userid/PIN authentication (directly imported from the SIS) while also allowing our CAS server to perform user lookups on the username method of authentication, was in the Advanced Configuration field mapping of the Users data type in the Student Information Systems Data Integration section of the Learn admin.

There are a few steps that you’ll need to take to make this work – and all of these steps assume that you’ve already got a CAS server deployed that has been tested and is working.  I am also assuming that you’ve already added the Blackboard Learn system that you’re adding CAS to as a valid service URL in the deployerConfigContext.xml of your CAS server.  These steps are outside the scope of this article, but if you’re trying to make this work and can’t, leave a comment and I’ll try to assist.

Step One – Setting Up CAS in Bb Learn as an Authentication Option

The first thing you’ll need to do is visit the System Admin>Building Blocks>Authentication section of the Learn admin.   You’ll see a button at the top left of your screen that will say “Create Provider”.  Click this, and choose “CAS” from the drop down context menu.   This will take you to the basic configuration screen for this authentication provider, shown here:

Set the provider to “Active”, and make sure to choose “Batch UID” as the user lookup method.  This allows CAS to be provided as an authentication option without requiring that you change the value that you’re already using for your primary user lookup.

After clicking “Submit”, you’ll see the server listed as an available authentication provider in your Learn admin.  Click the small down arrow next to the name of this provider, and choose “CAS Settings” from the context menu that appears.

These settings are self-explanatory.  All you really need to provide by way of CAS settings are your server URL, and the URL of your logout servlet. Once this is done, we can move on to configuring your integration to allow CAS to lookup your users.

Step Two – Configuring SIS Integration

Visit the “Student Information System Integrations” section of your admin.  Find the SIS integration that you’re currently using with your system, and click the down arrow next to it, choosing “Advanced Configuration” from the drop down menu that appears.

You’ll be taken to a screen that lists the various Learn object types that you can configure.   Each object type allows you to provide your own field mapping definitions that match the Learn object value attributes to the XML that you’re pulling from your SIS.

Find the “Users” object type, and click the small arrow next to the name, choose “Field Mapping” from the context menu that appears.

By default, the field “Change on Update” for the element “Replacement Batch UID” should not be checked. Go ahead and check this value. This is going to allow you to provide a new value pulled from the XML that will serve as your Batch UID that CAS will use to match your user that is attempting to login.   In the last step, when setting up CAS as an authentication type, we told the authentication provider to use the Batch UID as our lookup mechanism rather than the default Learn username value.  In this way, we allow either the new “CAS” username to work for authentication, or the traditional username scheme we were already using in the Learn environment.

Step Three – Mapping an XML Value to the Replacement Batch UID

Now we need to tell Learn what data we want to use from our XML file as our new Batch UID – and subsequently as the value we want CAS to match the username on.  As I said in the introduction, in our environment, the username scheme we use has the first portion of the users email address serve as the username.   In the “Replacement Batch UID” row of the Users Field Mapping, I am going to choose “Use a custom script” in the “Source Field” column.   Custom scripts in Learn are really just snippets of Javascript that reference learn object types.  Depending on the type of integration that you’re using, the docs for that integration should provide you a description of which elements from your XML map to which Learn object types. Based on the integration type I’m using, I know that the data in the XML I want is going to be a part of the users email address, which in the IMS Enterprise Vista 1.1 Integration is mapped to the data.email object. I can then write a simple custom script that tells Learn to set this Replacement Batch UID to the value of a variable that grabs that first portion of the data.email object.

Because our source SIS is also a bit inconsistent about how the email address is entered, I am also including a preemptive bit of script to make sure that all usernames are imported in to the system using similar casing.

The custom script would look something like:

[content_box]var uname = data.email.split(“@”)[0]; uname = uname.toLowerCase(); uname;[/content_box]

Once this value is included as a secondary id for all the users I am importing from the SIS, the users should then be able to login using either their traditional userid, or using their username via the CAS system.