Download presentation
Presentation is loading. Please wait.
Published byLora Snow Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.