Different Approaches to Single-Sign-On

Jeff Kahn, Verbena Consulting

Topics We Will Cover

• Problem Domain• Uninteresting Cases• Simple Cases

– Username and Password– Provisioning a License Key

• More Complicated Cases– Desktop Application Push– Account Mapping– Standards-Based Approach (IMS Basic LTI)

Problem Domain

• Communication between Blackboard and some other system

• “Other” system requires a login• User logs in at most once (via user interface)

Uninteresting

Uninteresting Case

• URL in Blackboard to a site without login, e.g. weather.com

Uninteresting Case

Push Content to Blackboard

Simple Challenge to Login to Blackboard

Simple

Simple Cases

• Building Block holds credentials such as username / password– Managed through Properties / Settings pages

• Ways to Send Credentials– In the clear– Basic Authentication (not so secure)– Digest access authentication (more secure)– Set a Cookie– Encryption

Provisioning(redirect)

• Skip case of process outside Blackboard• Request a key by redirecting to a sign-up site• Useful with an approval workflow• Note change in “look and feel”

– Loss of Blackboard look– Reinforce other system’s brand

Properties / Settings Pages

Requested by E-mail

• Notification of events– Request key, enter key, etc.– Support business purposes such as “credit” for a

sign-up.

• Issues– Sending mail from Blackboard may not be enabled– E-mail should not be sent to a specific person

Identifying Instances Uniquely

• Dynamically provisioned once– Submit a customer ID, get a web services key in

response.– Systems are now “paired”.

• Distribute shared secret.

Portal Info Classes

PortalExtraInfo pei = PortalUtil.loadPortalExtraInfo(null, null, ”myConfig");

ExtraInfo ei = pei.getExtraInfo();

ei.setValue(”foo", “some value”);myVar = ei.getValue(”foo");

PortalUtil.savePortalExtraInfo(pei);

import blackboard.portal.data.ExtraInfo;import blackboard.portal.data.PortalExtraInfo;import blackboard.portal.servlet.PortalUtil;

More Complex

Access as Specific bbUser

Desktop Application to Blackboard

• Publishing content to Blackboard– Unknown Bb access method in place

• Step 1: User Accesses Building Block– Requires login– Creates access token mapped to bbUsername– Copy token and paste into application

SoftChalk Key Creation

Step 2: NOSESSION holds REST handler

Step 3: Application passes access token with each request

Recap

• User logs in somehow• We generate a token and associate it with their

bbUsername. • Application stores this token.• Application passes this token to JSP in the

“NOSESSION” folder– a folder containing files without Bb page tags that

can be accessed without an access challenge.

• JSP maps token back to bbUsername.• We now have a logged in user.

Map to External Account

Account Mapping

• Associate Bb user with same user in other system

• Optimistic Mapping (never a UI challenge)• Declared Mapping (user facilitated mapping)

Optimistic Account Mapping

• Both accounts exist– Accounts can be mapped with Bb user data (email)

• Fetch email out of Bb use for login• Wrinkles

– Email not in place– Email address not the same

• multiple accounts, different address purpose

• Variant: Provision accounts in the other system from bbUsernames or e-mails.

Create or Map

Map

Create

Declared Mapping• First Time

– Try using Bb data– Offer an option to substitute

• Allow for account creation– Redirect to site or sign-up form in B2

– Store what worked• configuration file• UserRegistry classes

• Next Time– Fetch what was stored the first time– Allow for a change it what will work

• Depends on Remote System API

UserRegistry Classes

UserRegistryEntry ure = UserRegistryEntryDbLoader.Default.getInstance().

loadByKeyAndUserId(”fooKey", userId);

String fooKey = ure.getValue();

import blackboard.data.registry.*;import blackboard.persist.registry.*;

Standards-Based Launch Data

IMS Basic Learning Tools Interoperability

• http://www.imsglobal.org• Required and optional parameters:

– User ID, Role, Name, Email– Resource and Context ID– Custom

• Key and secret (OAuth)• Alliance• Allure of single development effort

– wrapped inside building block

Issues

• No data returned ( there is “Outcomes”)

• Subtle LMS-specific integration– e.g. name and description with link– Single or multiple– LMS not required

• User part of key to identify

• Documentation and Support– Admin and Instructor Controls– How to add a BLTI Link

• BLTI Links part of Common Cartridge v1.1

Barnes & Noble NOOK Study

• Textbook list and links no longer stored in Blackboard– Move from license key to key and secret.– Textbook and link list no longer stored in

Blackboard

• Converted Building Block to BLTI Tool Provider

Distribute a Shared Encryption Secret

• Website to request key and secret.• Back-end generates pair and emails to provider,

end-user, or both.• User enters key and secret.

Barnes & Noble NOOK Study

• Same code supports – Angel, D2L, Jenzabar, Moodle, Sakai, WebCT

• Blackboard supports BLTI in SP4– Also supports BLTI links in Common Cartridges

Jeff Kahn

jeffkahn@verbenaconsulting.com

www.verbenaconsulting.com

Q&A

Please provide feedback for this session by emailingDevConFeedback@blackboard.com.

The title of this session is:

Different Approaches to Single-Sign-On from Blackboard to Other Systems