As part of our anatomy of a new InFlight integration series of posts we’ve discussed how each new InFlight target system integration has 6 core components; Basic Authentication, SSO Authentication, Basic Content Retrieval, Addressing JavaScript Errors, Advanced Content Retrieval, Look and Feel. In this post, we will be looking at how Blackboard implements Single Sign-on (SSO) and how to setup InFlight to leverage SSO to provide an even more seamless experience to your end users.

First off, let’s look at what Blackboard provides.  Blackboard provides what it calls the AutoSignon Building Block which allows an institution to implement a Single Sign-on (SSO) solution.  Once a user has been authenticated by a trusted source, such as a campus portal, intranet, a request can be made to the AutoSignon Building Block which will automatically log the user in and redirect them to the requested content without requiring authentication.

Before continuing, we’ll make the assumption that the AutoSignon Building Block is for Blackboard as we aren’t going to discuss installation here.

Blackboard handles Single Sign-on (SSO) by targeting a URL which accepts parameters containing the information necessary to verify the credentials of the user.  For instance, let’s say a user wants access to their Personal Information which can be accessed at,

The way Blackboard accepts SSO for this URL, would be to actually target,

Let’s take a look at these parameters in more detail.

userId – The name of the request parameter which contains the User Id (user’s Batch Uid).

auth – The name of the request parameter which contains the MAC.

timestamp – The name of the request parameter which contains the timestamp.

forward – The name of the request parameter which contains the URL for forwarding.

The userId parameter is straightforward such that it corresponds to the Blackboard User ID for the user who is trying to access the content.

The auth parameter is more interesting because it contains something called the MAC.  What is the MAC?  MAC stands for message authentication code.  It is generated by the trusted system in order to determine the integrity of an SSO request.

By default, the parameters used to generate the MAC are a Shared Secret which is specified in the settings of the AutoSignon Building Block, the userId and timestamp.  The trusted system will concatenate these values, encrypt the result using the MD5 algorithm and convert it to a 32-byte alphanumeric (hexadecimal) string to make it URL-friendly.  When the request is received by Blackboard Learn, it will validate the MAC based on its own settings to ensure that the system indeed is a trusted source.

The timestamp parameter is simply the time at which the request is being made.  This states how long the MAC will be valid for based on when the request was generated and when it was received by the AutoSignon Building Block.

Finally, the forward parameter contains the URL which the end user wants to access, in this case,

The redirect to the SingleSignon Building Block only needs to be done on the first URL access. Once the user has been considered authenticated by Blackboard Learn, they can simply go about using Blackboard as normal.

That’s it!

Now let’s see how InFlight integrates with Blackboard’s Single Sign-on and how we can deliver a more transparent and seamless experience to the end user.

To demonstrate this, we will create a new SharePoint page which targets the Personal Information content in Blackboard.  To start we need to modify our Licensed Host entry within the InFlight Protected configuration file.






description=”TestEdu Dev Environment”










We can ignore most of the fields here for our discussion, but the field which we added is the sharedSecret parameter which specifies the Shared Secret Blackboard has specified in its settings for generating the MAC.  Once we’ve specified the sharedSecret, we can go ahead and setup our SharePoint page!

Let’s create a new SharePoint page which will contain an InFlight Viewer WebPart that will target the Personal Information page.  We will create the new SharePoint page in SitePages and we’ll call it PersonalInformation.  As well, we will add an InFlight Viewer Web Part to the Page.


Now that the page is setup, let’s edit the InFlight Viewer’s WebPart properties.  We want to target the Personal Information page, so let’s expand the Content URL options and enter the following url into the textbox;

Ensure the Enable Single Sign-On checkbox is enabled within the Basic Properties, shown below. Once that is complete, click OK and let’s test it out!


If we navigate to, which is the SharePoint page we created, we now see the following;


At no point was the user requested to authenticate, it just worked!  What did InFlight do here?

As seen above, we set the Target URL to be

But if we look in Fiddler, we can see that InFlight transformed the request to our Blackboard Learn server to be,

This occurs because it was aware that Single Sign-on authentication was required.  InFlight generated the correct MAC and passed the required Single Sign-on information to Blackboard Learn.  Blackboard Learn recognized that the request was coming from a trusted source and forwarded the user to the desired content.

Now let’s click Edit Personal Information to ensure that we don’t need to worry about authentication anymore.


Again, no need to authenticate!  Great!  Here we can see how InFlight provides transparent and seamless integration with Blackboard Learn, without the user having to worry about whether they’re accessing another system or being required to authenticate themselves.  All the user needs to worry about is the task at hand.

Leave a Reply

Copy link