Shibboleth

1
Shibboleth

• Authenticate Locally, Act Globally
• A Penn State Case Study

2
Agenda

• Shibboleth - Background and Status
• Technical Review -- how does it work?
• Shibboleth - Why?
• Penn State Background
• Shibbified Penn State Applications
• Integrating Shibboleth with the PSU
  infrastructure
• Future

3
What is Shibboleth?

• An initiative to develop an architecture and
  policy framework supporting the sharing between
  domains -- of secured web resources and services
• Built on a Federated Model
• A project delivering an open source
  implementation of the architecture and framework
• Deliverables
• Software for Origins (campuses)
• Software for targets (vendors)
• Operational Federations (scalable trust)

4
Shibboleth Goals

• Use federated administration as the lever have
  the enterprise broker most services
  (authentication, authorization, resource
  discovery, etc.) in inter-realm interactions
• Provide security while not degrading privacy.
• Attribute-based Access Control
• Foster inter-realm trust fabrics federations and
  virtual organizations
• Leverage campus expertise and build rough
  consensus
• Influence the marketplace develop where
  necessary
• Support for heterogeneity and open standards

5
Attribute-based Authorization

• Identity-based approach
• The identity of a prospective user is passed to
  the controlled resource and is used to determine
  (perhaps with requests for additional attributes
  about the user) whether to permit access.
• This approach requires the user to trust the
  target to protect privacy.
• Attribute-based approach
• Attributes are exchanged about a prospective user
  until the controlled resource has sufficient
  information to make a decision.
• This approach does not degrade privacy.

6
Stage 1 - Addressing Four Scenarios

• Member of campus community accessing licensed
  resource
• Anonymity required
• Member of a course accessing remotely controlled
  resource
• Anonymity required
• Member of a workgroup accessing controlled
  resources
• Controlled by unique identifiers (e.g. name)
• Intra-university information access
• Controlled by a variety of identifiers
• Taken individually, each of these situations can
  be solved in a variety of straightforward ways.
• Taken together, they present the challenge of
  meeting the user's reasonable expectations for
  protection of their personal privacy.

7
So What is Shibboleth?

• A Web Single-Signon System (SSO)?
• An Access Control Mechanism for Attributes?
• A Standard Interface and Vocabulary for
  Attributes?
• A Standard for Adding AuthN and AuthZ to
  Applications?

8
Shibboleth Status

• Software Availability
• Version 1.1 available August, 2003
• Version 1.2 available March, 2004
• Version 1.3 available Summer, 2003
• Target implementation - works with Apache and IIS
  targets
• Campus Adoption accelerating
• Working with second round of information vendors
• Java target implementation underway
• Work underway on some of the essential management
  tools such as attribute release managers, target
  resource management, etc.

9
Shibboleth Status

• Likely to coexist well with Liberty Alliance and
  may work within the WS framework from Microsoft.
• Growing development interest in several
  countries, providing resource manager tools,
  digital rights management, listprocs, etc.
• Used by several federations today NSDL,
  InQueue, SWITCH and several more soon (JISC,
  Australia, etc.)

10
High Level Architecture

• Federations provide common Policy and Trust
• Destination and origin site collaborate to
  provide a privacy-preserving context for
  Shibboleth users
• Origin site authenticates user, asserts
  Attributes
• Destination site requests attributes about user
  directly from origin site
• Destination site makes an Access Control Decision
• Users (and origin organizations) can control what
  attributes are released

11
Technical Components

• Origin Site Required Enterprise Infrastructure
• Authentication
• Attribute Repository
• Origin Site Shib Components
• Handle Server
• Attribute Authority
• Attribute Release Policy
• Target Site - Required Enterprise Infrastructure
• Web Server (Apache or IIS)
• Target Site Shib Components
• SHIRE
• SHAR
• WAYF
• Resource Manager

12
Shibboleth AA Process
WAYF
Users Home Org
Resource Owner
Resource
13
Shibboleth Architecture (still photo, no moving
parts)
14
Attribute Authority --Management of Attribute
Release Policies

• The AA provides ARP management tools/interfaces.
• Different ARPs for different targets
• Each ARP Specifies which attributes and which
  values to release
• Institutional ARPs (default)
• administrative default policies and default
  attributes
• Site can force include and exclude
• User ARPs managed via MyAA web interface
• Release set determined by combining Default and
  User ARP for the specified resource

15
Typical Attributes in the Higher Ed Community

16
Trust, and Identifying Speakers

• Federations distribute files defining the trust
  fabric
• Individual sites can create bilateral trust
• When a target receives a request to create a
  session, the Authn Assertion must be signed by
  the origin (PKI validation), and the origin must
  be a member of a common Federation.
• When an Origin receives a request for
  attributes, it must be transported across SSL.
• The name of the Requestor (from the certificate)
  and the name of the user (mapped from the
  Handle) are used to locate the appropriate ARP.

17
Target Managing Attribute Acceptance

• Rules that define who can assert what..
• MIT can assert student_at_mit.edu
• Chicago can assert staff_at_argonne.gov
• Brown CANNOT assert student_at_mit.edu
• Important for entitlement values

18
Managing Authorization

• Federations will NOT require members to do
  business with each other
• Target manages Access Control Policy specifying
• what attributes must be supplied
• and from which origins
• in order to gain access to specific resources
• Rules are attribute based

19
What are federations?

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Built on the premise of
• Initially Authenticate locally, act globally
• Now, 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

20
Shibboleth -- Next Steps

• Full implementation of Trust Fabric
• Supporting Multi-federation origins and targets
• Support for Dynamic Content (Library-style
  Implementation in addition to web server plugins)
• Sysadmin GUIs for managing origin and target
  policy
• Grid, Virtual Organizations
• ? Saml V2.0, Liberty, WS-Fed
• NSF grant to Shibboleth-enable open source
  collaboration tools
• LionShare - Federated P2P

21
Penn State Background

• 24 campus locations
• Distributed Computing Environment (DCE)
• 184,556 Principals
• User managed groups
• MIT Kerberos V
• Fully populated, production 4/1
• IBMs LDAP 5.1
• eduPerson

22
Why Shibboleth?

• True collaborative effort
• Open Source/Open Standards
• Solves todays problems
• Leverages existing infrastructure
• Authentication agnostic
• Emphasis on privacy (FERPA)
• Position to co-exist/support other federated
  identity solutions on the horizon
• We like Ken.

23
Pilot with WebAssign

• Summer 2002
• 20 students, 2 weeks, 1 course
• Fall 2002
• 200 students
• 3 courses
• Spring 2003
• 1800 students
• Successful login 63,026
• All courses at UP location can use Shibboleth
• Now in Limited Production

24
WebAssign

• Historically, first two weeks -
• 25 to 30 questions/day
• Almost all are login problems

This semester - Numbers of queries in the
Shibbilized courses ..1 or 2/day A reduction
of 85 Numbers of queries in the normal courses
remain at 15/day
25
Napster

• Requirement to Authenticate locally, Act
  Globally. Sound Familiar.
• Created 2 teams of PSU/Napster staff
• MDS
• Caching Server, Networking, etc
• Authentication/Registrationprocess
• Shibboleth

26
Penn State Origin Site

• 7 Origin servers
• 2 WebAssign
• 5 Napster
• Load balance using SLB
• Software
• Shibboleth 1.1
• Hardware
• IBM Blade HS20 proc 2.4GHz mem 2.5Gig

27
Penn State Origin Site

• Currently member of InQueue
• Will join InCommon ASAP
• Not using WAYF
• Used to access external web resources

28
Future

• Shibboleth Meteor Gateway
• ATT Wireless
• Use Shibboleth to access PHEAA from student web
  applications
• Use Shibboleth Phase II for non Web applications
  such as LionShare (P2P)
• Continue to pilot with library vendors
• Currently working with JSTOR, OCLC
• eZProxy
• Incorporate University of Michigans Cosign
  (WebISO) with our origin site

29
THE END

• Acknowledgements
• Design Team David Wasley (U of C) RL Bob
  Morgan (U of Washington) Keith Hazelton (U of
  Wisconsin (Madison))Marlena Erdos (IBM/Tivoli)
  Steven Carmody (Brown) Scott Cantor (Ohio State)
• Important Contributions from Ken Klingenstein
  (I2) Michael Gettes (Duke), Scott Fullerton
  (Madison)
• Coding Derek Atkins (MIT), Parviz Dousti (CMU),
  Scott Cantor (OSU), Walter Hoehn (Columbia)