1. Columbia Educational Resources Online: A Shib-Enabling Case Study Carol Kassel Columbia University Digital Knowledge Ventures (DKV) Copyright Carol Kassel 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. Table of contents Background Why we used Shibboleth Project details Key players Caveats Challenges Success! Future plans

3. Background Digital Knowledge Ventures: develops and distributes digital resources beyond CU’s campus Created “e-seminars” (3-5-hour learning experiences based on CU courses) Available to CU community on campus (free) and individual consumers (paid) Free registration on Columbia Interactive Paid registration on Fathom

4. E-Seminar Example

5. Columbia Interactive Sample Page

6. Columbia Interactive Registration

7. Along Came CERO Changes in market, demise of Fathom: new audiences sought Began licensing content for institutional subscribers, with free trial available to all Required new, cleaner site: Columbia Educational Resources Online (CERO) Access to CERO: IP address or username/ password, all contained in Universal Registration System (URS)

8. CERO Sample Page

9. Reaching out to alumni University Development and Alumni Relations (UDAR) approached DKV: address need to reach out to alumni Goal: to provide alumni access to CU online resources, such as e-seminars Alumni already have usernames, called University Network IDs (UNIs) New site to be built: Learning@Columbia, e- seminar gateway for alumni

10. Why we used Shibboleth Problem 1: How could we allow access to seminars via UNI login and still handle existing audiences? Problem 2: How could we maintain security of UNI system in all transactions? Problem 3: How could we make login process smooth and seamless? Problem 4: How could we require login once and keep users logged in for duration of browser session? Answer: Shibboleth!

11. Project details: Audiences Three audiences: CU affiliates with valid UNI/password Non-CU users with valid username/password Users at subscribing institutions with valid IP address CERO already served first two, so we selected CERO to be Shibboleth target (Service Provider)

12. Shibboleth setup

13. Shibboleth origin (IdP) 1: CU CU origin existed for NSDL, but needed customization for CERO Login form uses WIND (Web Identification Network Dæmon), CU’s preferred Web ISO Standard interface maintains uniform look and feel – inspires user trust All information secure

14. CU origin login UI

15. Shibboleth origin (IdP) 2: URS URS origin did not exist yet; needed to be set up Previously, sole UI was basic authorization pop-up box Custom UI needed to be built; cobranded with DKV and CU Press logos for future scalability

16. URS origin login UI

17. WAYF Existing users would have one more click (WAYF) before logging in Goal: make WAYF as plain as possible to direct users appropriately Must allow for the addition of more origins in the future

18. WAYF design

19. Other details IP address recognition would take place outside of Shibboleth Different ARPs for each origin: CU origin provides EPPN; URS origin provides EPPN, subscribed resources, expiration Logging process changes to accommodate web usage reporting

20. Sample.htaccess file

21. Key players Walter Hoehn (Electronic Publishing Initiative at Columbia (EPIC), now University of Memphis): expertise in Shibboleth Noah Levitt (EPIC): creator of URS, no previous Shibboleth experience Andrew Johnston, Steve McGrath (Academic Information Systems (AcIS)): WIND developers, server configuration handlers, no previous Shibboleth experience Carol Kassel (DKV): project manager, no previous Shibboleth experience

22. Caveats (how hard can it be?) Many pieces to the puzzle – takes longer than you think – pad your schedule! Eye-opening details for those who had not worked with Shibboleth before Some CERO-specific details required thought and workarounds “Necessary evils” (example to follow)

23. Necessary evil example

24. Challenge 1: Learning@Columbia Learning@Columbia would contain list of “featured seminars” Assumption: most L@C users would be alumni – bypass the WAYF? Additional: redirect users to seminar “splash page” Solution: create redirect page in protected area, with hardcoded link to CU origin login

25. Learning@Columbia Design

26. Seminar splash page

27. Shib-enabled login process

28. Challenge 2: Web server Shib already running on alternate web server, not main web servers Decision: move CERO to alternate web server – do not install Shib on main web servers Some disadvantages to doing so, but benefits outweighed them

29. Challenge 3: Certificates Login info must be passed securely among all Shib components Requires several certificates, some internal, some external Purchased new cert and repurposed existing certs CU origin still requires user to download certs – some friction for alumni

30. Challenge 4: Server config changes CU origin fairly straightforward Brand-new origin setup (for URS) had more details than expected Several intricate config changes required in dev, test, and production machines

31. Challenge 5: “cero” vs. “www.cero” 2 different URLs: cero.columbia.edu and www.cero.columbia.edu Everything set up for cero but not www.cero! Rude awakening at testing time; scrambled to fix

32. Success! Deployed November 2003 Very little downtime; very few technical problems Promotion to alumni in Feb 2004: excellent response rate, no major issues

33. Possible future applications Move away from IP address auth to Shib for subscribing institutions who have that capability Shib-enable other websites Deploy Shib on main web servers