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
import blackboard.portal.data.ExtraInfo;
import blackboard.portal.data.PortalExtraInfo;
import blackboard.portal.servlet.PortalUtil;
PortalExtraInfo pei = PortalUtil.loadPortalExtraInfo(null,
null, ”myConfig");
ExtraInfo ei = pei.getExtraInfo();
ei.setValue(”foo", “some value”);
myVar = ei.getValue(”foo");
PortalUtil.savePortalExtraInfo(pei);
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
import blackboard.data.registry.*;
import blackboard.persist.registry.*;
UserRegistryEntry ure =
UserRegistryEntryDbLoader.Default.getInstance().
loadByKeyAndUserId(”fooKey", userId);
String fooKey = ure.getValue();
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
Q&A
Jeff Kahn
jeffkahn@verbenaconsulting.com
www.verbenaconsulting.com
Please provide feedback for this session by emailing
DevConFeedback@blackboard.com.
The title of this session is:
Different Approaches to Single-Sign-On from Blackboard
to Other Systems