Using Shibboleth as Your WebSSO Authentication System

CAMP Shibboleth: Enabling Campus and Federated Single Sign-On

June 27, 2006

Brendan BellinaIdentity Services Architect

University of Southern CaliforniaEmail: 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 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.

DisclaimerInformation 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 Application,Single System

Single Sign On… In The Beginning

Internal User

Single Sign On Via Shibboleth

Diagram from shibboleth.internet2.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 (IdP)

4. SP requests and receives user attributes from IdP

5. SP allows or denies access to resource based on attributes

“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…

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.

ApplicationsI’m Bob

Bob

Bob

Bob

Bob

Single Identity Consistently Communicated

ApplicationsHe’s Bob

Bob

Bob

Bob

Bob

Student System

Employee System

Donor System

Student Bob

Staff Bob

Donor Bob

The Need to Resolve Identity

IdMSystem

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?

This exercise left to the reader

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!

Campus Identity and Service Providers

Campus Identity and Service Providers

Campus Identity and Service Providers

Campus Identity and Service Providers

Extending Services to an External User

Deployment CostsSoftware: 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)

Staff Responsibilities / RolesTechnologists

- 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

Staff Responsibilities / RolesPolicy 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

RequirementsShibboleth 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

IssuesDepartments 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 (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...

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 CommitteesAll 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

LinksShibboleth website: http://shibboleth.internet2.edu

Shibboleth Wiki: https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/WebHome

USC AuthX 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