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 systems brand
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
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
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.
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.
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
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 firstname.lastname@example.org www.verbenaconsulting.com Q&A
Please provide feedback for this session by emailing DevConFeedback@blackboard.com. DevConFeedback@blackboard.com The title of this session is: Different Approaches to Single-Sign-On from Blackboard to Other Systems