Shibboleth:
Building Tools for Inter-institutional Resource Sharing
InCommon:
A Shibboleth-based Research and Education Federation
Renee Woodten Frost
Internet2 Middleware and Security
5 Feb 2005
Topics
 A Bit O’ Background - Internet2, Middleware, NMI
 What is Shibboleth? What is its Current Status?
 Why Shibboleth? Who is Using Shibboleth?
 What are Federations?
 InCommon
 Work with Other Federations
• International R&E Federations
• Federal e-Authentication work
• Commercial – WS-Fed
 For more information
5 Feb 2005
What is Middleware?
 Specialized networked services that are shared by
applications and users
 A set of core software components that permit scaling of
applications and networks
 Tools that take the complexity out of application
integration
 A second layer of the IT infrastructure, sitting above the
network
 A land where technology meets policy
 The intersection of what networks designers and
applications developers each do not want to do
5 Feb 2005
A Map of Campus Middleware Land
5 Feb 2005
Core Middleware Scope
 Identity and Identifiers – namespaces, identifier
crosswalks, real world levels of assurance, etc.
 Authentication – campus technologies and policies,
interrealm interoperability via PKI, Kerberos, etc.
 Directories – enterprise directory services architectures
and tools, standard objectclasses, interrealm and registry
services
 Authorization – permissions and access controls,
delegation, privacy management, etc.
 Integration Activities – open management tools, use of
virtual, federated and hierarchical organizations, enabling
common applications with core middleware
5 Feb 2005
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, Tom Barton (Chicago), Scott
Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Duke),
Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark
Poepping (CMU), Lynn McRae (Stanford), David Wasley (retired
California), Von Welch (Grid)
 European members - Brian Gilmore (Edinburgh), Ton Verschuren
(Netherlands), Diego Lopez (Spain)
 Creates working groups in major areas, including directories, interrealm
access control, PKI, video, P2P, etc.
 Works via conference calls, emails, occasional serendipitous in-person
meetings...
5 Feb 2005
Internet2 Middleware and
the NSF Middleware Initiative (NMI)
 Internet2 Middleware a major theme for the last five years, drawing
support from 200+ university members, 75+ corporate members, and
government grants and interactions
 Internet2 has an integrator role within NMI, the key NSF Program to
develop and deploy common middleware infrastructures
 NMI has two major themes
• Scientific computing and data environments (Grids)
• Common campus and inter-institutional middleware infrastructure
(Internet2/EDUCAUSE/SURA work)
 Issues periodic NMI releases of software, services, architectures,
objectclasses and best practices
• R6 in Dec 04 most current release
5 Feb 2005
The Model:
Enterprises and Federation
Given the strong collaborations within the academic
community, there is an urgent need to create inter-realm
tools, so
 Build consistent campus and enterprise middleware
infrastructure deployments, with outward facing
objectclasses, service points, etc. and then
 Federate those enterprise deployments, using this
outward facing campus infrastructure, with inter-realm attribute
transports, trust services, etc. and then
 Leverage that federation to enable a variety of applications
from network authentication to instant messaging, from video
to web services, and then, going forward
 Create tools and templates that support the management
and collaboration of virtual organizations by building on the
federated campus infrastructures.
5 Feb 2005
What is Shibboleth? (Biblical)
 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)
5 Feb 2005
What is Shibboleth?
 An initiative to develop an architecture and policy framework
supporting the sharing – between domains -- of secured web
resources and services
 A framework built on a “Federated” model
 A project delivering an open source implementation of the
architecture and framework
 Deliverables:
• Software for Credential Providers (campuses)
• Software for Resource Providers (content, services, etc)
• Operational Federations (scalable trust)
5 Feb 2005
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
• Using 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 heterogeneity and open standards
5 Feb 2005
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.
5 Feb 2005
Typical Attributes in the
Higher Ed Community
Affiliation
“active member of community” member@washington.edu
EPPN
Identity
gettes@duke.edu
Entitlement
An agreed upon opaque URI
urn:mace:vendor:contract1234
OrgUnit
Department
Economics Department
EnrolledCourse
Opaque course identifier
urn:mace:osu.edu:Physics201
(eduPersonPrincipalName)
5 Feb 2005
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 situation can be solved in a variety of
straightforward ways.
 Taken together, they present the challenge of meeting users’
reasonable expectations for protection of personal privacy.
5 Feb 2005
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 Authentication and Authorization to
Applications?
5 Feb 2005
Shibboleth Architecture
(still photo, no moving parts)
5 Feb 2005
Shib Update
 Project formation - Feb 2000
 Inception of SAML effort in OASIS – December 2000
 OpenSAML release – July 2002
 Shib v1.0 April 2003
 Shib v1.1 July 2003
 Shib v1.2 April 2004; Shib v1.2.1 November 2004
 Shib v1.3 1Q05 – non web services, e-Auth certified
 Shib v1.4 WS-Fed compliant
 OpenSAML 2.0 – relatively soon
 Shib 2.0 – 3Q05?
5 Feb 2005
Shibboleth Status
 Campus adoption accelerating and working with increasing
number of information/service providers - over 50 universities
using it for access to OCLC, JSTOR, Elsevier, WebAssign,
Napster, etc.
 Common status is “moving into production”
 The hard part is not installing Shibboleth but running “plumbing” to
it: directories, attributes, authentication
 Work underway on some of the essential management tools such
as attribute release managers, resource management, etc.
 Needs federations to scale; being adopted by, or catalyzing,
national R&E federations in several countries
5 Feb 2005
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, listprocs, etc.
 UK’s JISC 2004 awards for Core Middleware: Technology
Development Programme – 8 of 15 involve Shib
 Used by several federations today – NSDL, InQueue,
SWITCH, and several more soon (UK, Australia, Finland,
etc.)
5 Feb 2005
Shibboleth – Some Next Steps
 Full Implementation of Trust Fabric
• Supporting multi-federation credential and resource providers
 Support for Dynamic Content
 SysAdmin GUIs for managing credential and resource
policy
 Integration with SAML V2.0, Liberty Alliance, WS-Fed
 NSF grant to Integrate Shib with Grids
 NSF grant to Shibboleth-enable open source collaboration
tools
5 Feb 2005
Why Shibboleth?
Improved Access Control
 Use of attributes allows fine-grained access control
• Med School Faculty get access to additional resources
• Specific group of students have access to restricted resources
 Simplifies management of access to extended
functionality
• Librarians, based on their role, are given a higher-than-usual
level of access to an online database to which a college might
subscribe
• Librarians and publishers can enforce complicated license
agreements that may restrict access to special collections to
small groups of faculty researchers
5 Feb 2005
Why Shibboleth?
Federated Administration
 Flexibly partitions responsibility, policy, technology, and trust
 Leverages existing middleware infrastructure at home
organization/credential provider - authentication, directory
• Users registered only at their “home” or “origin” institution
• Resource Provider does NOT need to create new userids
 Authorization information sent instead of authentication
information
• When possible, use groups instead of people on Access Control Lists
• Identity information still available for auditing and for applications that
require it
5 Feb 2005
Why Shibboleth?
Privacy
 Higher Ed has privacy obligations
• In US, “FERPA” requires permission for release of most
personal identification information; encourages least
privilege in information access
• HIPAA requires privacy in medical records handling
 General interest and concern for privacy is growing
 Shibboleth has active (vs. passive) privacy provisions
“built in”
5 Feb 2005
Benefits to Campuses
 Much easier Inter-Domain Integration
• With other campuses
• With off-campus service provider systems
 Integration with other campus systems, intra-domain
• Learning Management Systems
• Individual dept/school-specific needs
 Ability to manage access control at a fine-grained level
 Allows personalization, without releasing identity
 Implement Shibboleth once…
• And then just manage attributes that are released to new resource providers
5 Feb 2005
Benefits to Resource Providers
 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 Shibboleth integration work completed on vendor’s systems
• 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
 Enables attribute-based Service Level Model
 If universities have Shibboleth implemented already, easy
implementation for them
5 Feb 2005
What are Federations?
Associations of enterprises that come together to
exchange information about their users and resources
to enable collaborations and transactions
 Enroll and authenticate and attribute locally, act federally.
 Uses federating software (e.g. Shibboleth), common attributes
(e.g. eduPerson), and a set of security and privacy
understandings
 Enterprises/users retain control over attributes released to
resource; Resources retain control (may delegate) over
authorization decisions
5 Feb 2005
Business drivers for federations
 Research and education
• Access to and sharing of digital content
• The visiting scientist and eduRoam
• Inter-institutional courseware
• Grids and collaborative tools
5 Feb 2005
Requirements for federations
 Federation operations
 Federating software
• Exchange assertions
• Link and unlink identities
 Federation data schema
 Federation privacy and security requirements
 Federations should be positioned to support both web
services and direct applications
5 Feb 2005
Policy Basics for Federations
 Enterprises that participate need to establish a trusted
relationship with the operator of the federation; in small or
bilateral federations, often one of the participants operates the
federation
 Participants need to establish trust with each other on a per use
or per application basis, balancing risk with the level of trust
 Participants need to agree on the syntax and semantics of
shared attributes
 Privacy issues must be addressed at several layers
 All this needs to be done on a scalable basis, as the number of
participants grow and the number of federations grow
5 Feb 2005
Federal Guidelines of Relevance
 NIST Guideline on Risk Assessment Methodologies
 NIST Guideline on Authentication Technologies and
their strengths
 Federal e-Authentication Efforts
5 Feb 2005
US Shibboleth Federations
 InQueue
 InCommon
•
•
•
•
Uses
Management
Policies
Shared schema
 Club Shib
 NSDL
 State, system, and campus federations
• Texas, Ohio State, etc…
5 Feb 2005
The Research and Education
Federation Space
REF
Cluster
Other
potential
US
R+E
feds
InQueue
(a starting
point)
Other
clusters
Other national
nets
SWITCH
InCommon
NSD
L
Indiana
The Shib
Researc
h Club
State of Penn
Fin Aid Assoc
Slippery slope
- Med Centers, etc
5 Feb 2005
InQueue
 The “holding pond”
 Is a persistent federation with “passing-through”
membership…
 Operational today. Can apply for membership via
http://shibboleth.internet2.edu
 Requires eduPerson attributes
 Operated by Internet2; open to almost anyone using
Shibboleth in an R&E setting or not…
 Fees and service profile to be established shortly: costrecovery basis
5 Feb 2005
Some InQueue Credential Providers
Brown University
Cal Poly Pomona
Carnegie Mellon University
Columbia University
Cornell University
Dartmouth College
Duke University
Georgetown University
Georgia State University
Internet2
London School of Economics
Michigan State University
National Research Council of Canada
New York University
Penn State University
Rutgers University
The Ohio State University
The University of Kansas
University of Alaska Fairbanks
University of Arkansas
University of Bristol
University of Buffalo
UCLA
University of California, San Diego
University of California Shibboleth Pilot
University of Colorado at Boulder
University of Michigan
University of Minnesota
University of Missouri - Columbia
University of North Carolina at Chapel Hill
University of Rochester
University of South Dakota
University of Southern California
UT Arlington
UTHSC-Houston
University of Virginia
5 Feb 2005
University of Wisconsin
What is InCommon?
A Shibboleth-based Research and
Education Federation for the US
A public-sector, large-scale, persistent
federation
5 Feb 2005
Federation
 Federation operations – Internet2
 Federating software – Shibboleth 1.2 and above
 Federation data schema - eduPerson200210 or later and
eduOrg200210 or later
 Federated approach to security and privacy with posted policies
 Became fully operational mid-September, with several early
entrants shaping the policy issues.
 Precursor federation, InQueue, has been in operation for about
a year and will feed into InCommon; approximately 150
members
 http://www.incommonfederation.org
5 Feb 2005
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
5 Feb 2005
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.)
5 Feb 2005
Management
 Legal - initially LLC, likely to take 501(c)3 status
 Governance
• Steering Committee: Carrie Regenstein, chair (Wisconsin), Jerry Campbell
(USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Ken
Klingenstein (I2), Mark Luker (EDUCAUSE), Tracy Mitrano (Cornell), Susan
Perry (Mellon), Mike Teets (OCLC), David Yakimischak (JSTOR)
• Two Steering Committee advisory groups
– Policy: Tracy Mitrano, Chair
– Communications, Membership, Pricing, Packaging:
Susan Perry, Chair
• Technical Advisory Group: Scott Cantor (OSU), Steven Carmody (Brown),
Bob Morgan (UWash), Renee Shuey (PSU)
• Project manager: Renee Woodten Frost (Internet2)
5 Feb 2005
Operations
 Operational services by Internet2
• Storefront (process maps, application process)
• Backroom (CA, WAYF service, etc.)
• Federation Operating Practices and Procedures (FOPP)
 InCommon Process Technical Advisory
•
•
•
•
Scott Cantor, OSU
Jim Jokl, University of Virginia
RL Bob Morgan, University of Washington
Jeff Schiller, MIT
 Key Signing Party
• March 30, 2004 in Ann Arbor
• Videotaped and witnessed
5 Feb 2005
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
5 Feb 2005
Pricing
 Goals
• Cost recovery
• Manage federation “stress points”
 Prices
• Application Fee: $700 (largely enterprise I/A, db)
• Yearly Fee
– Higher Ed participant: $1000 per identity management system
– Sponsored participant: $1000
– All participants: 20 ResourceProviderIds included; additional
ResourceProviderIds available at $50 each per year, available in
bundles of 20
5 Feb 2005
Trust in
- initial
 Members trust the federated operators to perform its activities well
• The operator (Internet2) posts its procedures
• Enterprises read the procedures and decide if they want to become members
• Contracts address operational and legal issues
 Origins and targets establish trust bilaterally in out-of-band or noband arrangements (using shared posting of practices)
• Origins must trust targets dispose of attributes properly
• Targets must trust origins to provide attributes accurately
• Risks and liabilities managed by end enterprises, in separate ways
– Collaborative apps are generally approved within the federation
– Higher risk apps address issues through contractual and legal means
5 Feb 2005
Members trust
Operations
 The federation operations presents limited but real
exposures in identity proofing members properly and in
the metadata management
 InCommon publishes its procedures for identity proofing
and its operational procedures
• InCommon Certificate Authority CP/CPS
• Metadata management process
 Individual enterprises read the policies and decide
whether to trust the federation operations and how to
assign liability
5 Feb 2005
Operations Docs
 InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1
• An outline of the procedures to be used if there is a disaster with the InCommon Federation.
 Internet2_InCommon_Federation_Infrastructure_Technical_Reference_ver_0
.2
• Document describing the federation infrastructure.
 Internet2_InCommon_secure_physical_storage_ver_0.2
• List of the physical objects and logs that will be securely stored.
 Internet2_InCommon_Technical_Operations_steps_ver_0.35
• This document lists the steps taken from the point of submitting CSR, Metadata, and CRL to issuing a signed
cert, generation of signed metadata, and publishing the CRL.
 Internet2_InCommon_Technical_Operation_Hours_ver_0.12
• Documentation of the proposed hours of operations.
5 Feb 2005
CA Operations Docs
 CA_Disaster_Recovery_Procedure_ver_0.14
• An outline of the procedures to be used if there is a disaster with the CA.
 cspguide
• Manual of the CA software planning to use.
 InCommon_CA_Audit_Log_ver_0.31
• Proposed details for logging related to the CA.
 Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compromise_v
er_0.2
• An outline of the procedures to be used if there is a root key compromise with the CA.
 Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61
• Draft of the PKI-Lite CPS.
 Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21
• Draft of the PKI-Lite CP.
 Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federation_
System_Technical_Reference_ver_0.41
• Document describing the CA.
5 Feb 2005
Participant Agreement Highlights
 Agree to post policies
• Security
– Basic identity management
• Privacy
 Inform InCommon on a timely basis of key compromise
 Be responsible for ResourceProviderIds issued
 Be responsible for adhering to their POPS statement
 Stay timely on metadata
5 Feb 2005
Members Trusting Each Other:
Participant Operational Practice Statement
 Basic Campus identity management practices in a short,
structured presentation
• Identity proofing, credential delivery and repeated authentication
• Provisioning of enterprise-wide attributes, including entitlements
and privileges
 Basic privacy management policies
• Standard privacy plus
• Received attribute management and disposal
5 Feb 2005
Trust Pivot Points in Federations
 In response to real business drivers and feasible
technologies, need to increase the strengths of:
• Campus/enterprise identification, authentication practices
• Federation operations, auditing thereof
• Campus middleware infrastructure in support of Shib (including
directories, attribute authorities and other Shib components) and
auditing thereof
• Relying party middleware infrastructure in support of Shib
• Moving in general from self-certification to external certification
5 Feb 2005
International Federation Peering
 Shibboleth-based federations in the UK, Netherlands,
Finland, Switzerland, Australia, Spain, and others
 International peering meeting October 14-15 in Upper
Slaughter, England
 Issues include agreeing on policy framework, comparing
policies, correlating app usage to trust level, aligning
privacy needs, working with multinational service
providers, scaling the WAYF function
 Leading trust to Slaughter…
5 Feb 2005
Leading Trust to Slaughter
5 Feb 2005
Three Types of Issues
 Internal federation issues
• Business drivers – educational, research, admin – helping each
country find a reason
• Cookbook – key issues and common touchpoints
• Alignment with other trust services such as PKI
 Inter-federation issues
• Needs for agreements
– Authentication context, attributes
• Needs for legal frameworks
– Assignment of roles within federation between
– Treaties/MOU between federations
 Union of federations issues
5 Feb 2005
Inter-federation Agreements
 Protocols
• Shib on the outside; generally Shib within
• Versioning issues
 Data
•
•
•
•
Authn context field – structure and values
LOA – US Federal guidelines, the Australian points system, etc.
Eduperson, eduOrg and cross-mappings
Persistent identifiers
 Trust
• Federation operations
• Inter-federation legal agreements
• Member statements
– Formats
– Controlled vocabulary
5 Feb 2005
League of Federations
 Brand, logo, presence
 Handling international resource-providers
 Qualifying new members
 Relationship to other sector activities, particularly
government (and health services)
 Support for virtual organizations
 Promoting its use for applications: eduRoam, GLIF, Grids
 EU Privacy issues
 International WAYF
 Universal InQueue
5 Feb 2005
Leading Trust from Slaughter
5 Feb 2005
Immediate International Issues
 “International WAYF” – management of the user
experience
• List of Federations that contain IdPs
• Where to put multi-nationals?
• Handling of exceptions in a consistent fashion
 Privacy
• EU Privacy directives intended for attributes associated with identity
• Rules for interior and exterior privacy may be different for EU
• And then there’s the Swiss…
5 Feb 2005
Federal Government
 Federal E-Authentication has a number of pilots under
way. One of them is now Shib.
 Phase 1 and Phase 2 efforts funded, with deliverables
due over the next six months
• Policy framework comparison submitted Oct 7
• Technical interoperability demonstrated October 14
• Policy discussions and applications meetings now occurring
 Potential phase 3 and 4 would include working on a
federal federation and peering with Higher Ed and other
federations – meetings underway
5 Feb 2005
WS-Fed and Shib
 Verbal agreements to build WS-Fed interoperability
• Contract work commissioned by Microsoft, executed by Shib core
development
• Contracts executed and work likely this Spring
 Discussions broached, by Microsoft, in building Shib
interoperabilty into WS-Fed
 Devils in the details
5 Feb 2005
For More Information
 Websites
http://middleware.internet2.edu
http://shibboleth.internet2.edu
http:/www.incommonfederation.org
Renee Woodten Frost
rwfrost@internet2.edu
5 Feb 2005