Shibboleth Architecture and RequirementsShibboleth

A New Approach to Web Based Access Control

CNIApril 4, 2005

Overview

• Shibboleth Update– Introduction to Shibboleth

– Project Status

– InCommon Status

– Adoption Status

– How Are Campuses Using Shibboleth Today?

• The Conversion from IP-based Access Control to Shibboleth

• … Open Discussion

What is Shibboleth?

• An Architecture and Protocol– A set of profiles based on the OASIS SAML 1.1 standard

• A Project sponsored by Internet2/MACE– Charged with defining the Shibboleth Arch, developing an

open source implementation, and supporting the deploy of Shibboleth through the Higher Ed environment

– Develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services

• An Implementation of the Shibboleth Architecture– Developed by the I2/MACE Shibboleth Project

– There are other independent implementations

Key Concepts

• A Secure Framework for Managing Access Control

• Access Control Based On Attributes

• Active Management of Privacy

• Standards Based

• Federated Administration

• A Framework for Multiple, Scaleable Trust and Policy Sets (Federations).

• A Standard (yet extensible) AttributeValue Vocabulary

Attribute-based Authorization

• IP Address-based approach– The resource checks the browser's IP address against a

table. Browsers using an IP address assigned to campus X are given campus X’s authorizations

– Most campuses run proxy servers, to allow access from off-campus

• Identity-based approach– The identity of a prospective user is passed to the controlled

resource and is used to determine whether to permit access. – This approach requires the user to trust the resource to

protect privacy.

• Attribute-based approach– Attributes are exchanged about a prospective user until the

controlled resource has sufficient information to make a decision. Identity MAY be an attribute…

– This approach does not degrade privacy.

Benefits to Campuses

• Much easier Inter-Domain Integration– With other campuses

– With off-campus vendor systems

• Integration with other campus systems, intra-domain– LMS

– Med School……

• Ability to manage access control at a fine-grained level

• Allows personalization of services, without releasing identity

• Implement Shibboleth once…– And then just manage attributes that are released to new

targets

Benefits to Services/Vendors

• Shibboleth is built on open standards• Unified authentication mechanism from the vendor perspective

– Much more scalable– Much less integration work required to bring a new customer online.

• Ability to implement fine-grained access control (e.g. access by role), allowing customer sites to effectively control access by attributes and thus control usage costs, by not granting access unnecessarily

• Once the initial Shibboleth integration work has been completed on the vendor’s systems– The incremental cost of adding new customers is relatively minimal– In contrast to the current situation -- requiring custom work for each new

customer

• Ability to offer personalization• If your customers have Shibboleth implemented, easy

implementation of service for them

Shibboleth (the Implementation) Status

• V1.2.1 available fall 2004• In production use by commercial information

providers (eg EBSCO, Elsevier SD, OCLC)• Growing international takeup (countrywide

deploys in HE underway in Switzerland, Finland, UK, Australia, and others…)

• Deploy rate on US campuses accelerating….• Production Federations now available• Recent meeting of “League of Federations”• On track for certification by US Federal E-

Authn Initiative

Shibboleth -- Next Steps

• Plan for a Multi-Federation World

• Improved management tools

• Shibboleth 1.3 available May 2005– Reduces reliance on inflexible PKI validation code

– e-Auth, compliance

– WS-Fed compliance in 1.3.x

• Shibboleth 2.0, using SAML 2.0, represents greatly enhanced functionality; work begins after 1.3 is released

• Shibboleth project will be segmented and expanded

• Extended beyond the web; some flows may not use all existing components in the same way

What are federations?

• An association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions.

• Built on the premise of – “Enroll and authenticate and attribute locally, act federally.”

• Federation provides only modest operational support and consistency in how members communicate with each other

• Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision.

• Over time, this will all change…

What is

• A Shibboleth-based Research and Education Federation for the US

• A public-sector, large-scale, persistent federation

Principles

• Support the R&E community in inter-institutional collaborations

• InCommon itself operates at a high level of security and trustworthiness

• InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc

• InCommon will be constructive and help its participants move to higher levels of assurance as applications warrant

• InCommon will work closely with other national and international federations

Uses

• Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, OCLC, EBSCO, Pro-Quest, etc.)

• Institutions working with outsourced service providers, e.g. grading services, scheduling systems

• Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.

• (Shared network security monitoring, interactions between students and federal applications, peering with international activities, etc.)

Participants

• Two types of participants:– Higher ed institutions - .edu-ish requirements

– Resource providers – commercial partners sponsored by higher ed institutions, e.g. content providers, outsourced service providers, etc

• Participants can function in roles of identity providers and/or resource providers– Higher ed institutions are primarily identity (credential)

providers, with the potential for multiple service providers on campus

– Resource (service) providers are primarily offering a limited number of services, but can serve as credential providers for some of their employees as well

Adoption Status - Campuses

• So you’ve got a Shibboleth IdP operational

• … and you’re wondering “what do I do with it?”

• … here are profiles of several campuses, describing their plans for using Shibboleth to control access to services in the intra- and inter-domain

How Are Campuses Using Shibboleth Today?

• 150+ campuses at some stage of deploy

• Some Examples– Penn State

– Ohio State University

– Duke

– Univ of Texas System

– Univ of Southern California

Penn State

• Strategy– Position your university for a new way of doing

business with federated approach

– Take privacy issues seriously

– Targets of opportunity

Penn State

• Sequence – currently in production– WebAssign + Physics Dept

• Physics Dept maintaining 1000+ userids and passwords every semester at a remote site

• Shibboleth got them out of that business• Help desk calls related to password problems dropped

75%

– Napster• Authenticated access• preserve privacy• Indicate whether or not user is authorized to use service

Penn State

• Next steps– Pennsyvania Higher Education Assistance

Agency(PHEAA)

– Piloting:  with • Digital Library Technology department, • OCLC, • JSTOR, • Elsevier• ProQuest

– LionShare's – secure P2P file sharing

Ohio State

• Strategy– Establish a comfort level running and supporting

the software and ironing out usability problems while staying internal so that the coordination and support issues are simpler.

– The priority is on converting existing applications…. Don't know when the external opportunities will be important enough to pursue

– Deploying it internally is a bet that the external applications will be important in the future

Ohio State

• Sequence– Internal library application (EZProxy) (authn will

no longer mean authz)

– Internal low-volume/impact applications (begin replacing local SSO)

– External library applications (Jstor/EBSCO/OhioLink/etc)

– Internal high-volume applications

University of Texas & UT Federation

• 16 institutions with origins used for inter-institutional access.

–Authenticated wireless access at the UT System Office.–UT institutions – cross institution security site.–Being strongly considered for authX for the employee

benefits system for all 16 institutions.–Pilot for library access–A UT Federation provides some shortcuts through the

policy and legal processes as all of the institutions fall under the same governing board and legal service.

Across Texas

•UT Houston and Baylor will be using shib enabled web application for medical resident evaluations. This is considered by AAMC as a very common issue.

•Being considered for cross institutional access to web based resources in the Texas Medical Center (44 independent institutions). First will be the Texas Medical Center Library via ETR grant.

•Rice and A&M are considering sharing some library resources.

Univ. of Southern California

• Currently in Production–Napster (music download service) -- different levels of service are available to different audiences; the subsets currently are 'students' and 'faculty' (or maybe 'faculty/staff').

–Scholar's Portal (specialized library portal) -- see http://library.usc.edu/ (click link at the upper right); I think this is open to anyone in the USC community

–myUSC Portal (general web portal) -- See https://my.usc.edu/ -- everybody at USC

–Software.usc.edu -- the software download server for desktop sw licensed generally to USC (e.g., Acrobat Pro, Symantec, Timbuktu etc etc);

–Assorted random stuff ( e.g. blogs, asst departmental apps, like music, theater & USCard)

Univ. of Southern California

• “Real Soon Now” – Blackboard

– Library online resources (e.g., EBSCO)

– Webreg -- web-based class registration

Adoption Status - International

• UK - JISC has decreed that Shibboleth will replace Athens SSO by 2007

• Switzerland– deployed at all all HE sites– Access to licensed resources

• Finland– Countrywide Shib-enabled MetaLib

• Australia– Access to licensed resources– Shib-enabled Dspace

• China– Pilots underway…..

Content Provider Adoption

• Elsevier Science Direct• OCLC• EBSCO• JSTOR• ArtStor• Pro-Quest• Exlibris (sfx, MetaLib)• Dynix• Thompson/Gale• EZProxy• LMS Systems (Blackboard, WebCT, Sakai..?)• ….

The Conversion from IP-based Access Control to Shibboleth

• Role of the Library– Manage licenses

– Manage Attribute Release

• Role of the Campus IT Organization– Operate the campus middleware infrastructure

– Operate the Person Registry (and attributes)

– Operate the Shibboleth infrastructure

• Role of the Federation– Manage the metadata

– Manage the trust infrastructure

Managing the Conversion -

• Managing the Mixed Environment– Mix of Shib-enabled and non-Shib-enabled

vendors– Persistence of URLs when a vendor converts to

Shibboleth (eg on a course web page)

• The Changing User experience– Login now required, even on campus– Authorization implemented – some people may no

longer have access

• Other Issues– Library walkins– Avoiding the Federation WAYF

Why Campuses Should Begin the Transition Now…

• Compelling Applications Becoming Available– 30 “outward-facing” Federal applications by Oct 2005

• Once a campus deploys Shibboleth, all applications can use it.– The library transition can leverage existing IT effort

• Shibboleth addresses current problems– Problems with IP (access from off-campus, guest access to

campus IP space)– Problems with Proxies– Problems managing “charge per search” situations

• Shibboleth provides additional functionality and flexibility– Personalization with privacy– Fine-grained access control by community– Fine-grained control with sfx

Open Discussion

• Questions?

• What are Your Concerns about Migrating to Shibboleth?

• What Topics Should we Cover During the ALA Workshop?