Columbia Educational Resources Online: A Shib-Enabling Case Study

Carol KasselColumbia UniversityDigital 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.

Table of contents

BackgroundWhy we used ShibbolethProject detailsKey playersCaveatsChallengesSuccess!Future plans

Background

Digital Knowledge Ventures: develops and distributes digital resources beyond CU’s campusCreated “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 InteractivePaid registration on Fathom

E-Seminar Example

Columbia Interactive Sample Page

Columbia Interactive Registration

Along Came CERO

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

CERO Sample Page

Reaching out to alumni

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

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!

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)

Shibboleth setup

Shibboleth origin (IdP) 1: CU

CU origin existed for NSDL, but needed customization for CEROLogin form uses WIND (Web Identification Network Dæmon), CU’s preferred Web ISOStandard interface maintains uniform look and feel – inspires user trustAll information secure

CU origin login UI

Shibboleth origin (IdP) 2: URS

URS origin did not exist yet; needed to be set upPreviously, sole UI was basic authorization pop-up boxCustom UI needed to be built; cobranded with DKV and CU Press logos for future scalability

URS origin login UI

WAYF

Existing users would have one more click (WAYF) before logging inGoal: make WAYF as plain as possible to direct users appropriatelyMust allow for the addition of more origins in the future

WAYF design

Other details

IP address recognition would take place outside of ShibbolethDifferent ARPs for each origin: CU origin provides EPPN; URS origin provides EPPN, subscribed resources, expirationLogging process changes to accommodate web usage reporting

Sample .htaccess file

Key players

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

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 beforeSome CERO-specific details required thought and workarounds“Necessary evils” (example to follow)

Necessary evil example

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

Learning@Columbia Design

Seminar splash page

Shib-enabled login process

Challenge 2: Web server

Shib already running on alternate web server, not main web serversDecision: move CERO to alternate web server – do not install Shib on main web serversSome disadvantages to doing so, but benefits outweighed them

Challenge 3: Certificates

Login info must be passed securely among all Shib componentsRequires several certificates, some internal, some externalPurchased new cert and repurposed existing certsCU origin still requires user to download certs – some friction for alumni

Challenge 4: Server config changes

CU origin fairly straightforwardBrand-new origin setup (for URS) had more details than expectedSeveral intricate config changes required in dev, test, and production machines

Challenge 5: “cero” vs. “www.cero”

2 different URLs: cero.columbia.edu and www.cero.columbia.eduEverything set up for cero but not www.cero!Rude awakening at testing time; scrambled to fix

Success!

Deployed November 2003Very little downtime; very few technical problemsPromotion to alumni in Feb 2004: excellent response rate, no major issues

Possible future applications

Move away from IP address auth to Shib for subscribing institutions who have that capabilityShib-enable other websitesDeploy Shib on main web servers