Using Shibboleth as Your Web SSO Authentication System

Using Shibboleth as Your Web. SSO 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. edu

Copyright Brendan Bellina, 2006. This work is the intellectual property of the author. Permission is granted for this material to be shared for noncommercial, 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.

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.

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

Using Shibboleth as an Authentication System

Shibboleth does not do Authentication.

Questions

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

Single Sign On Via Shibboleth Diagram from shibboleth. internet 2. edu

(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 (Id. P) 4. SP requests and receives user attributes from Id. P 5. SP allows or denies access to resource based on attributes

“Knock-Knock” Protocol • • • Information in this document is subject to change without notice. The names of companies, User (to Service Provider): Knock, Knock 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. SP: Who’s there? (tolaws Id. P Complying with all applicable copyright is the handle responsibility ofservice) 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 Id. P: (to of. SP SHIRE) Officers User of the University 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 SP (SHAR): User who? (to Id. P AA) 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, Id. P (AA): User gi. Lv 2 Uz. Shib@scope. edu andnor or otherwise, does not necessarily constitute or imply its endorsement, recommendation, favoring by EDUCAUSE or any agency thereof, nor The Officers of the University of Southern California. The viewsmy and opinions of authors expressed herein do not necessarily my name is and email is and… 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.

Single Identity Consistently Communicated Bob Applications I’m Bob Bob

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

Does Single Identity Mean Single Access? 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…

This exercise left to the reader

Shibboleth as Web. SSO - Shibboleth 1. 3 and earlier are completely agnostic about authentication because… Shibboleth does not do authentication. - USC has used Pub. Cookie for authentication since 2002 and with Shibboleth 1. 3 is switching to using Tom. Cat with JNDI and retiring Pub. Cookie. - Technical Questions? Attend the Web. SSO Panel at 4: 00 in this room!

Campus Identity and Service Providers

Extending Services to an External User

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

Staff Responsibilities / Roles Technologists - Central Shibboleth administrator for Id. P: - 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

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

Requirements Shibboleth Id. P 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 Id. M for visitors may be required if local data is required in addition to remote data

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.

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.

USC Department Developer Process - Department decides to provide a service to a population of users in the directory (Id. P) - 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. . .

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.

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

Links Shibboleth website: http: //shibboleth. internet 2. edu Shibboleth Wiki: https: //authdev. it. ohiostate. edu/twiki/bin/view/Shibboleth/Web. Home USC Auth. X website: http: //www. usc. edu/its/services/authx USC GDS website: http: //its. usc. edu/~bbellina/gds Contact the author via email: bbellina@usc. edu

Questions