Different Approaches to Single-Sign-On

1. Different Approaches to Single-Sign-On Jeff Kahn, Verbena Consulting

2. 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)

3. Communication between Blackboard and some other system “Other” system requires a login User logs in at most once (via user interface) Problem Domain

5. Uninteresting

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

7. Uninteresting Case

8. Push Content to Blackboard

9. Simple Challenge to Login to Blackboard

10. Simple

11. 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

12. 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

13. Properties / Settings Pages

15. 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

17. Identifying Instances Uniquely • Dynamically provisioned once • Submit a customer ID, get a web services key in response. • Systems are now “paired”. • Distribute shared secret.

19. 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);

20. More Complex

21. Access as Specific bbUser

22. 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

23. SoftChalk Key Creation

25. Step 2: NOSESSION holds REST handler

26. Step 3: Application passes access token with each request

27. 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.

28. Map to External Account

29. Account Mapping • Associate Bb user with same user in other system • Optimistic Mapping (never a UI challenge) • Declared Mapping (user facilitated mapping)

30. 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.

31. Create or Map

32. Map

33. Create

34. 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 • UserRegistryclasses • Next Time • Fetch what was stored the first time • Allow for a change it what will work • Depends on Remote System API

35. UserRegistryClasses importblackboard.data.registry.*; importblackboard.persist.registry.*; UserRegistryEntryure = UserRegistryEntryDbLoader.Default.getInstance(). loadByKeyAndUserId(”fooKey", userId); String fooKey = ure.getValue();

36. Standards-Based Launch Data

37. 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

38. 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

39. 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

40. 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.

41. 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

42. Q&A Jeff Kahn jeffkahn@verbenaconsulting.com www.verbenaconsulting.com

43. 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