1. Shibboleth @ Penn State Steve Kellogg Penn State University 4/20/2004

2. Penn State 24 Campuses 100,000+ Users Large scale integrated infrastructure –“Penn State Access Account” Auth Domain K4/AFS/PH; circa ’92 DCE/DFS; circa ’95 K5/LDAP; circa ’03 (Need a filesystem)

3. Why was Shibboleth Interesting? True Collaborative effort Open Source/Open Standards Solves today’s problems Leverages existing infrastructure Authentication agnostic Privacy (FERPA)

4. Shib at Penn State A clear need –Physics Dept. use of WebAssign at NCSU –Dept. account administration Fine for hundreds Realized the pain of thousands Proposal to set up server at NCSU to use our KDCs (Denied!)

5. Pilot w/ WebAssign Summer of 2002 –~20 Students, 2 weeks, 1 course Fall 2002 –~200 Students –3 Courses Spring 2003 –~1800 Students –63,026 successful authentications –Limited Production

6. More Shib @ Penn State A decision by the university came down Fall 2003 –Provide Napster to on-campus students by 1/12/2004 Immediate Thoughts –Preserve I1 bandwidth –Use Access Accounts –Time to invent, develop, test, deploy

7. Napster Quickly formed two teams –Caching Server team Multimedia Delivery System, MDS –Registration System team Clear need to authenticate locally and act globally –Shibboleth

8. Napster Concern; Shib is heavyweight and anticipated high demand on opening day Developed a test suite (Perl) –Simulated transaction flow – In-house test target –Then live Napster target Varied number of concurrent sessions and sleep duration between sessions

9. Napster performance testing Concluded w/ Napster that >8 sec would be too long Studies indicated 25 concurrent sessions max per origin server. Many thousands of on-campus students 5 Intel blades, Load balanced via Cisco 6509 w/SLB feature

10. Shib – Next Steps Expand Napster service to rest of the population InCommon for new deployments LionShare Additional corporate and other expressed interest

11. Summary Shibboleth was an obvious solution for both WebAssign and Napster Current implementation is pretty heavy weight Transaction times can be long, but was able to manage via loadbalancing origin site Look forward to more efficient implementation