ShibbolethService Providers:

Ohio State Experiences

Scott Cantor

cantor.2@osu.edu

The Ohio State University

Internet2/MACE© Scott Cantor 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.

Outline

OSU Background

Deployment Procedures

Applications and Approaches

Challenges

OSU Deployment Background

Pilots in late 2003, production since mid-2004

Initially deployed on Shibboleth 1.2, IdP and most SPs now on Shibboleth 1.3

Up to ~60,000-100,000 logins per day, servers are mostly idle

Nearly all applications restricted to one IdP

OSU Deployment BackgroundIdP Staging server plus two production servers in the same rack Linux, 2 x 3.4Ghz, 2G RAM Authentication to Kerberos via Tomcat JAAS Realm Attributes extracted from relational databases, cached locally in

MySQL, redundant lookups for same-day accounts in real time

TomcatJAAS

K5

ApacheShibboleth

MySQLMS-SQL

Sybase

freebcp

OSU Deployment BackgroundSP

~65 unique SPs exist internally plus WebAssign

Majority are Windows/IIS, plus a handful of Linux, and one Macintosh site

ADFS probably a logical choice if we had an enterprise level AD, but we don’t

Majority of sites were legacy customers, less than 25% new deployments

Vast majority are in-house web applications

Deployment Methodology

No mandates apart from threatened discontinuation of legacy SSO software (currently hoping for Fall 2006)

Little central decision making or coordination, no special policies over usage

Reflects a personal investment/choice, not institutional will

Henry Ford CRM: Any SSO you like, as long as it’s Shibboleth

Deployment Methodology

Controlled pilots to establish IdP as a reliable service over a number of months

Developed Shibboleth@OSU web site with support materials and step-by-step deployment instructions, attribute reference, customized template files

Metadata and ARPs for internal SPs maintained by hand then pushed to production servers

Certificates issued by an OpenSSL CA for 2 years CSRs currently e-mailed then a phone call verifies a

hash of the request

OpenSSL Certificate Profile

Subject DN contains C, O, CN subjectAltName contains SP providerId unless

certificate is shared[ usr_cert ]

# These extensions are added when 'ca' signs a request.

subjectAltName=URI:https://carmen.osu.edu/shibboleth

SP metadata usually has no KeyDescriptor elements

Shared credential authorized with md:KeyDescriptor/ds:KeyInfo/ds:KeyName containing CN from credential

Deployment Methodology

Deployment effectively a continuation of existing practice, just better hardware and slightly better operational practices

Release of attributes for SSO has never been firmly regulated

Mostly defer to data access policies and rights surrounding ODS/Data Warehouse

FERPA controls are lax when it comes to internal systems

Application Characteristics

Variety of administrative and a few academic support applications: Carmen course management system BuckeyeLink student services (grades,

registration, degree audit, finanical aid) eReports business reporting system eResearch PI Portal Many other sundry applications, departmental

intranets

Application Characteristics

Most applications are in-house ASP or Cold Fusion (which is now Java-ish)

Most already developed to consume identity via CGI headers using legacy SSO system

Shibboleth software can emulate legacy system with minor exceptions, so majority of applications migrated with no code changes

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

Typical Attributes

Legacy identifiers, encouraging new apps to use EPPN until a pair-wise identifier is available

Names

Course and section entitlements

SSN

Brio

Online report generation tool, now Java based, running behind IIS

Supports external authentication via REMOTE_USER

Provisioning and authorization handled by data security group and Brio admins

Considered federating with Medical Center as well as campus IdP, didn’t happen

Desire2Learn

Natively supports local database and LDAP authentication, authorization is local

“Session creation” is a semi-exposed API in their ASP environment

Shibboleth (or any SSO) protects a “front-door” script that invokes the session creation process using a user identifier

LDAP w/ Kerberos plugin used for WebDAV

PathLore

Minor case, but worth noting as an example of how security really works in the world

Fairly dumb/closed application used for free short course registration

Integration would have cost thousands

Solution? Fake it, protecting registration page, warn the user, then self-sign up

Peoplesoft

HR, Financials, Procurement now, SIS and probably additional modules coming

Kerberos authentication not currently deemed acceptable, but with SIS coming…

Appears to support external authentication through the Java front-end

Either native Java SP or front-ending

Media Managerhttps://mediamanager.osu.edu/

Online tool for managing and sharing media collections, currently image-oriented

Great testbed for: Lazy session SP feature

SAML 2.0 request features like IsPassive

Guest access and e-mail based invitation

Federation

Challenges

Resourcing support of SPs: management tools for metadata, certificates

contact and help desk triage material

infrastructure for maintaining new attributes without adding new single point of failure

maintaining documentation

Communicating attribute release to users, let alone user control

Challenges

Convincing site administrators to take on responsibilities: Use community support resources, not Scott’s

email address

Monitor proper channels for security patches and apply them

Customize error pages and code applications to faciliate user support when problems occur

Take ownership

Challenges

Guest access

IdP Discovery

Login look and feel