1. Using Shibboleth as Your WebSSO Authentication System CAMP Shibboleth: Enabling Campus and Federated Single Sign-On June 27, 2006 Brendan Bellina Identity Services Architect University of Southern California Email: bbellina@usc.edubbellina@usc.edu

2. Copyright Brendan Bellina, 2006. 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.

3. Disclaimer Information in this document is subject to change without notice. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the responsibility of the user. This document was prepared as an account of work requested by EDUCAUSE. While this document is believed to contain correct information, neither EDUCAUSE nor any agency thereof, nor The Officers of the University of Southern California, nor any of their employees, makes any warranty, express or implied, or assumes any legal responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by its trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, nor favoring by EDUCAUSE or any agency thereof, nor The Officers of the University of Southern California. The views and opinions of authors expressed herein do not necessarily state or reflect those of EDUCAUSE or any agency thereof, nor The Officers of the University of Southern California. In fact the views and opinions expressed herein do not necessarily state or reflect those of the author, anyone in the near or extended family of the author, friends of the author, or pets of the author. We honestly don’t have any idea where this content came from.

4. Presentation Outline -Introduction -Using Shibboleth as an Authentication System -Questions

5. Using Shibboleth as an Authentication System

6. Shibboleth does not do Authentication.

7. Questions

8. Single Application, Single System Single Sign On… In The Beginning Internal User

9. Single Sign On Via Shibboleth Diagram from shibboleth.internet2.edu

10. (Simplified) Single Sign On Via Shibboleth 1.User requests service from provider (SP) 2.Service Provider requests authentication 3.SP requests and receives Principal from Identity Provider (IdP) 4.SP requests and receives user attributes from IdP 5.SP allows or denies access to resource based on attributes

11. “Knock-Knock” Protocol User (to Service Provider): Knock, Knock SP: Who’s there? (to IdP handle service) IdP: User (to SP SHIRE) SP (SHAR): User who? (to IdP AA) IdP (AA): User giLv2UzShib@scope.edu and my name is and my email is and…giLv2UzShib@scope.edu Information in this document is subject to change without notice. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the responsibility of the user. This document was prepared as an account of work requested by EDUCAUSE. While this document is believed to contain correct information, neither EDUCAUSE nor any agency thereof, nor The Officers of the University of Southern California, nor any of their employees, makes any warranty, express or implied, or assumes any legal responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by its trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, nor favoring by EDUCAUSE or any agency thereof, nor The Officers of the University of Southern California. The views and opinions of authors expressed herein do not necessarily state or reflect those of EDUCAUSE or any agency thereof, nor The Officers of the University of Southern California. In fact the views and opinions expressed herein do not necessarily state or reflect those of the author, anyone in the near or extended family of the author, friends of the author, or pets of the author. We honestly don’t have any idea where this content came from.

12. Applications I’m Bob Bob Single Identity Consistently Communicated

13. Applications He’s Bob Bob Student System Employee System Donor System Student Bob Staff Bob Donor Bob The Need to Resolve Identity IdM System

14. A person may need to log into a Shibbolized application in more than one way. A case in point: the student administrator Tonya Troy is a staff member who is responsible for administering the Blackboard application. She needs to be able to sign into Blackboard as an administrator. Tonya Troy is also an active graduate student who takes classes that use Blackboard resources. She needs to be able to sign into Blackboard as a student. She should not have administrator privileges when logging in to work with her classes. Fortunately there is a solution! And the solution is… Does Single Identity Mean Single Access?

15. This exercise left to the reader

16. Shibboleth as WebSSO -Shibboleth 1.3 and earlier are completely agnostic about authentication because… Shibboleth does not do authentication. -USC has used PubCookie for authentication since 2002 and with Shibboleth 1.3 is switching to using TomCat with JNDI and retiring PubCookie. -Technical Questions? Attend the WebSSO Panel at 4:00 in this room!

17. Campus Identity and Service Providers

21. Extending Services to an External User

22. Deployment Costs Software: Shibboleth -Open Source -Runs on Apache and Microsoft IIS Hardware: -depends on the IdP platform and SP platforms -At USC: $20-30k, IdP machines (2 redundant, high availability Sun 240 servers with dual 1.5GHz Ultra Sparc III processors, 8 GB RAM, 4-73 GB mirrored disks)

23. Staff Responsibilities / Roles Technologists -Central Shibboleth administrator for IdP: -must be able to work with both Attribute Authority and Service Providers -should participate on Shibboleth lists -needs to be familiar with Shibboleth Access Request Policies -Service Provider Integration specialist: -helps departmental technologists with technical installation and trouble-shooting of SP installations -should participate on Shibboleth lists -Distributed SP Technologists: -Specialists on departmental applications. Works with SP Integration specialist on installation of departmental SP -Should participate on Shibboleth user list

24. Staff Responsibilities / Roles Policy Facilitators -Organization Data Access Manager: -Helps walk SP’s through data request process and get approval for data release from Attribute Authority -Should be trusted by data stewards and able to communicate with them effectively -Works with data stewards to assist in formulating data release policies -Institution Point of Contact (for Federating) -Initial point of contact when contacted by members of another institution needing access to services -Facilitator when contacting other institutions to allow members access to their services

25. Requirements Shibboleth IdP and SP expertise required in central organization Shibboleth SP expertise required in departments Internal policy development required Inter-institutional policies required to support Federation and visitors IdM for visitors may be required if local data is required in addition to remote data

26. Issues Departments can be reluctant to make Authorization decisions based on data (they may prefer legacy data feeds or managing authorizations in the application db). Sometimes people need more than one type of account for applications that do not do roles well. Authorization exceptions need to be handled in some way. The more granular authorizations are defined the more exceptions are likely. Visitor institutions may have Shibboleth but not be prepared to Federate or have an appropriate point-of-contact for policy.

27. USC Policies -Data Access Policy required for access to production GDS content whether through Shibboleth, LDAP, or other protocols -Recommendation that authentication/authorization for new applications is via the GDS wherever technically possible (almost a mandate). This means Shibboleth or LDAP. In both cases the user credential is stored in Kerberos and binding is performed against the LDAP directory which uses a USC version of the Notre Dame Kerberos plug-in. -Developing policies to allow definition of visitors that need access to services, both those with and without Federation membership. -Developing Federation policies.

28. USC Department Developer Process -Department decides to provide a service to a population of users in the directory (IdP) -Department Developer drafts application data needs and fills out Data Access Form and submits to Director of Organizational Improvement who acts as Organization Data Access Manager and AA expert -Finalize data access in face-to-face meeting with Directory Expert Continued on next slide...

29. USC Department Developer Process -Directory and Shibboleth experts determine access policies, groups, entitlements, and ARP’s needed to support the data request. -Developers can begin testing and working with Shibboleth Integrator to install Shibboleth on their SP, but cannot release to production until… -Directory Steering Committee approves data access request -Data Access Request approval documented. Subject to annual review.

30. USC Collaborative Committees All committees are chaired by the Director of the Office of Organization Improvement Services Data Oversight Committee - operational committee -Focuses on operational issues related to data collection and the flow of data from the Systems of Record (SOR) into the Registry and between SOR’s -Attendees include technical representatives and managers from SOR departments and Global Directory Service (GDS) team -Meets bi-weekly, generally 6-8 attendees Global Directory Service (GDS) Executive Committee - management committee - Focuses on technical and staffing issues affecting direction and prioritizations - Attendees include management representatives from SOR’s and GDS team - Meets bi-weekly over lunch, generally 8-10 attendees Directory Steering Committee - management committee - Focuses on policy regarding data acquisition and release, integration, and communication - Attendees include senior management representatives from academic schools, administrative departments, security office, legal - Meets every 3 weeks over lunch, generally 15-20 attendees

31. Links Shibboleth website: http://shibboleth.internet2.eduhttp://shibboleth.internet2.edu Shibboleth Wiki: https://authdev.it.ohio- state.edu/twiki/bin/view/Shibboleth/WebHomehttps://authdev.it.ohio- state.edu/twiki/bin/view/Shibboleth/WebHome USC AuthX website: http://www.usc.edu/its/services/authxhttp://www.usc.edu/its/services/authx USC GDS website: http://its.usc.edu/~bbellina/gdshttp://its.usc.edu/~bbellina/gds Contact the author via email: bbellina@usc.edubbellina@usc.edu

32. Questions