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. Problem Domain Communication between Blackboard and some other system Other system requires a login User logs in at most once (via user interface)

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 systems 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 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;

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

35. UserRegistry Classes UserRegistryEntry ure = UserRegistryEntryDbLoader.Default.getInstance(). loadByKeyAndUserId(fooKey", userId); String fooKey = ure.getValue(); import blackboard.data.registry.*; import blackboard.persist.registry.*;

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. Jeff Kahn jeffkahn@verbenaconsulting.com www.verbenaconsulting.com Q&A

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