RL “Bob” Morgan, Washington
Steven Carmody, Brown
Scott Cantor, Ohio State
Marlena Erdos, IBM/Tivoli
Michael Gettes, Georgetown
Keith Hazelton, Wisconsin
David Wasley, UCOP
Ken Klingenstein, Director
Internet2 Middleware Initiative

Outline
Background
What is Shibboleth?
Shibboleth Communities of Interest
Shibboleth and PKI
Shibboleth and SAML and WebSSO
Using Shibboleth
Shibboleth milestones
Roll-out plan and next steps
Getting ready http://middleware.internet2.edu/shibboleth

MACE (Middleware Architecture
Committee for Education)
Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher education
Membership - Bob Morgan (UW) Chair, Scott Cantor (Ohio
State), Steven Carmody (Brown), Michael Gettes (Georgetown),
Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia),
Mark Poepping (CMU), Bruce Vincent (Stanford), David Wasley
(California), Von Welch (Grid)
European members - Brian Gilmore (Edinburgh), Ton
Verschuren (Netherlands)
Creates working groups in major areas, including directories, interrealm access control, PKI, medical issues, etc.
Works via conference calls, emails, occasional serendipitous inperson meetings...

Shibboleth
A word which was made the criterion by which to distinguish the
Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce sh, called the word sibboleth. See --Judges xii.
Hence, the criterion, test, or watchword of a party; a party cry or pet phrase.
Webster's Revised Unabridged Dictionary (1913) :

Shibboleth - What is it?
An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources
Will provide for the secure exchange of interoperable attributes which can be used in access control decisions
Controlled dissemination of attribute information, based on administrative defaults and user preferences
Shifts the model from passive privacy towards active privacy
Based on a federated administration trust framework
Vendor participation - IBM/Tivoli
Standards Alignment - OASIS/SAML
Open solution(protocols and messages documented rfc-style, open source implementation available)

Shibboleth - Why is it Needed?
Growing interest in collaboration and resource sharing among institutions
Provides ability to make access control decisions in a cross domain environment
Current approaches to problem (IP address filtering, identity matching, use of shared ids) have serious problems
Shibboleth will involve more than the architecture/implementation developed by the SAML participants (eg community-of-interest, privacy)

Founding assumptions
Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs.
Federated Administration
(Initially) disturb as little of the existing campus infrastructure as possible
Work with common, minimal authorization systems (eg htaccess)
Encourage good campus behaviors
Learn through doing
• There is very little experience with systems that allow users to manage the release of attribute information
Create a marketplace and reference implementations

Stage 1 - Addressing Three Scenario’s
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)
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.

Architectural Model
Browser User’s Origin Site Responsible for Authentication
Origin Site Entity Willing to Create and Sign Assertions
• Set of assertions about the user (Attribute/value pairs)
• User has control over disclosure
• Identity optional
• “active member of community”, “Associated with Course XYZ”
Target responsible for Authorization
• Rules engine
• Matches contents of assertions against ruleset associated with target object
Cross Domain Trust
• Implemented in communities
• Previously created between origin and target
• Perhaps there is a contract (information providers..)

Authorization Attributes
Typical Assertions in the Higher Ed Community
Affiliation
EPPN
Entitlement
OrganizationalUnit
EnrolledCourse
“active member of the community”
EPPN=gettes@georgetown.edu
Urn:mace:infovendor:contract1234
Economics Department
Physics 201

Implications of Shibboleth Design
Choices
Support all 3 scenarios (not just the library problem)
• -> need a mechanism to manage attribute release
Focus on Privacy Protection
• Both sites and users need to manage attribute release
Assume Origin Site Authenticates User
• Origin Site needs enterprise level authentication mechanism
• Should have Web Single Signon system
Target Site Authorizes User
• Need Trust Framework
• Need agreement on syntax and semantics of attributes
(eduPerson, custom agreements between pairs of sites)

Federated Administration
Origin Site
• Must have joined the appropriate communities
• May have created “reasonable” default attribute release policies
• Responsible for Identifying and registering users
• Responsible for Authenticating users
Browser User
• May have created specific attribute release policies
Target Resource Manager
• Manage policies governing access to the resource

Simple point-to-point model
Authentication
Service
Enterprise
LDAP directory client
Attribute authority
Service discovery service target
Protocols
Attribute requestor
Enterprise
LDAP directory
Policy enforcement enforcement points
Policv decision point
Grid directory
Video directory
Video directory

Shibboleth Architecture
Concepts - High Level
Browser
Origin Site
Pass content if user is allowed
Authorization Phase
Authentication Phase
First Access - Unauthenticated
Target Site
Target
Web
Server

Shibboleth Architecture
Concepts (detail)
Attribute
Server
Entitlements
Ent Prompt
Req Ent
Browser
Auth OK
Web Login
Server
Authentication
Second Access - Authenticated
Pass entitlements for authz decision
Target
Web
Server
Origin Site
Target Site

Shibboleth Flows Draft

Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF

Establishing a User Context

Getting Attributes and Determining Access

SHIRE
Indexical Reference Establisher
Destination site component responsible for context/session establishment
When there is no active session, redirects browser user to the
WAYF

WAYF
Where are You From?
The WAYF is the transition point from destination to origin site
HS when users contact a destination first.
Users can respond to the WAYF by indicating in “colloquial” fashion which institution can authenticate them.
The WAYF will determine the URL of the appropriate HS based on the user’s input.
A variety of nasty semantic attacks lurk!

Handle Server
Works with AA and local Web ISO system to associate a query handle with an authenticated browser user and generate a signed assertion
Performs its work in response to an Attribute Query Handle Request
(currently an unauthenticated HTTP GET)
AQHR contains
• SHIRE URL for acceptance of response via HTTP POST
• URL of desired resource/service at destination

SHIRE
Indexical Reference Establisher
Destination site component responsible for context/session establishment
Session establishment will commonly rely on traditional techniques (i.e. cookies).
The SHIRE accepts an assertion from a HS and associates the incoming handle with the session it creates.

SHAR
Attribute Requester
A SHAR makes attribute requests using the handle given it by the SHIRE.
Upon receiving a response (AQR), the SHAR…
…authenticates the response
…extracts the attributes
…checks attribute acceptance
• e.g. can an AA at MIT issue attributes for Harvard?

Attribute Authority
Responds to Attribute Query Messages (AQM) from SHAR
Allows for specification and management of ARPs
Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion

IBM Interest
Provides “Federated” administrative model
(as apposed to centralized or delegated)
• Leaves administration of user and authenticating user to requester’s site
• Leverages existing authentication/directory infrastructure
Privacy of requester preserved
Leverages SAML standard and will be one of its first “proof points”
Applies to B2B environments beyond current scope and definition

IBM and Tivoli’s commitment
IBM/Tivoli has been contributing to the architecture and design for over a year
IBM/Tivoli is committed to contributing to an open source implementation
• Prototype underway
IBM/Tivoli is committed to continuing to drive ubiquitous
Security standards
• Shibb is based on existing standards where they exist
• SAML, etc...

Shibboleth (and SAML)
Communities of Interest (COI)
(Ken Klingenstein)

D. Wasley’s PKI Puzzle
Fed Bridge
Vendor
Reso ur c es
Campus
Reso ur ces
Ser v er
Cer t s
Sh ib
Campus
PK I
CREN Root CA
Campus
Sy st ems
Dir ec t o r y
Educause HE Bridge
Cam pus
PKI
Cam pus
Sy s t em s
Dir ec t o r y
EDU
PK I
Hier ar c hy
COM
PK I
Hierar chy
PKI provides:
• St rong Aut hent icat ion
• Flexible Aut horizat ion
• Secure Digit al Signat ure
• Powerful Dat a Securit y

Shibboleth and PKI
Complimentary infrastructures wrt technology and policy
Technically,
• Shibboleth leverages existing campus authentication processes (and can use end-entity certificates for this process)
•
Shibboleth uses PKI to implement a multi-domain trust model
• Shibboleth’s primary use is for authorization and privacy
• PKI’s primary use is establishing identity across domains
• PKI can use Shibboleth to achieve privacy and authorization
Policy,
• Shibboleth establishes a collaborative trust model (flexible, quick, privacyenabled, etc.)
•
PKI establishes a legal trust model (binding, hierarchical, formal, etc.)

Shibboleth and SAML and WebISO
(R.L. “Bob” Morgan)

What Will it be Like to Use
Shibboleth?
Sample Browser Screens are available at:
• http://middleware.internet2.edu/shibboleth/mockups/index.html
Actual user interface being designed by five higher ed Schools of Information

Use - Go Directly To Target

Use - Specify Origin Site

Use - Local Authentication

Use - Target Page Displayed!

Use - Local Navigation Site

Use - “in the background”

Use - Target Page Displayed!

Milestones
Project formation - February 2000 Stone Soup
Process - began late summer 2000 with Tivoli commitment
(Marlena Erdos), project leadership fall (Steven Carmody), biweekly calls and scenario, requirements and architecture development
Linkages to SAML established December 2000 (consistent architecture and distinguished territory)
Architecture and protocol completion - Aug, 2001
Design - Oct 2001
Coding begins - Nov 2001

Roll-out plan
Basic coding stage through February 2002
Alpha pilots Feb and March 2002
Code rewrites March April
Beta pilots - April May
General release - June, 2002
Release issues: open-source license approach distribution - Apache and other components
CVS, Bugtraq, and source/enhancement management

Coding stage
Three coding teams:
CMU - origin IBM/Tivoli - target OSU - libraries
Approach is to integrate hard-wired components and then progressively replace hard-wiring with code
Dec, Jan, Feb - finish coding, testing
End of february - packaging
End of Feb - March - deploy code to early pilot sites

Profile of Pilot Sites
Member of campus community accessing licensed resource
• University hosting licensed DBs accessed from other universities
• Talking to several commercial vendors (they need “their customers” asking for this functionality…)
Member of a course accessing remotely controlled resource
• Web based testing
• Clearinghouse for curriculum packages
• Web based tools used in courses
Member of a workgroup accessing controlled resources
• Multi-institution project teams

Some of the pilots
Webassign
Penn State
Univ of Delaware - Problem Based Learning Clearinghouse
EDINA (UK)
London School of Economics

Getting Ready
As a Target
• think through web services architecture
• examine contracts with origins for attribute requirements, business rules and marketing options
As an Origin
• implement enterprise authentication infrastructure
• implement eduPerson in enterprise directory
• work with vendors to educate and take advantage
• ??

Identity Services on One Slide
Interrealm Objectclass standards
(e.g.eduperson, gridperson)
Content
Portals
Shibboleth exchange of attributes
Future
PKI
Security Domain
DODHE et al
Grids et al
Learning
Management
Systems
Web services and servers
WebISO
Campus authentication
Future PKI
Personal
Portals
Enterprise directory

Grids
Shibboleth, eduPerson, and everything else
OKI
Licensed
Resources
Embedded
App Security
JA-SIG & uPortal
Inter-realm calendaring futures
Campus web SSO
Shibboleth, eduPerson, Affiliated Directories, etc.
Enterprise authZ
Enterprise
Directory
Enterprise
Authentication
Legacy
Systems