Shibboleth:
Federated Identity Management
Renee Woodten Frost,
Internet2 Middleware and Security
23 April 2004
Agenda





What is Shibboleth?
Background and Status
Why Shibboleth?
Who is Using Shibboleth?
Federations
• InQueue
• InCommon
 For more information
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)
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 (service providers)
• Operational Federations (scalable trust)
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
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.
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
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.
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?
Shibboleth Architecture
(still photo, no moving parts)
Shibboleth Status
 Software Availability
•
•
•
•
Version 1.1 available August, 2003
Version 1.2 available April, 2004
Version 1.3 available Summer, 2004
Target implementation - works with Apache and IIS targets
 Campus Adoption accelerating…
 Working with second round of information vendors/service providers
 Java target implementation underway
 Work underway on some of the essential management tools such as
attribute release managers, target resource management, etc.
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 in UK, Australia, etc.)
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
Why Shibboleth?
Improved Access Control
 Use of attributes allows fine-grained access control
• Med School Faculty get access to additional 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
Why Shibboleth?
Federated Administration
 Flexibly partitions responsibility, policy, technology, and trust
 Leverages existing middleware infrastructure at origin- authn, directory
• Users registered only at their “home” or “origin” institution
• Target does NOT need to create new userids
 Authorization information sent, instead of authentication information
• when possible, use groups instead of people on ACLs
• identity information still available for auditing and for applications that require it
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
 General interest and concern for privacy is growing
 Shibboleth has active (vs. passive) privacy provisions “built in”
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, without releasing identity
 Implement Shibboleth once…
• And then just manage attributes that are released to new targets
Benefits to Targets/Service 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 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
 Enables attribute-based Service Level Model
 If your customers have Shibboleth implemented, easy implementation
for them
What are Federations?
 Associations of enterprises that come together to exchange
information about their users and resources in order to enable
collaborations and transactions
 Enroll and authenticate and attribute locally, act federally.
 Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*)
common attributes (e.g. eduPerson), and a security and privacy set
of understandings
 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.
 Several federations now in construction or deployment
Unified field theory of Trust
 Bridged, global hierarchies of identification-oriented, often
government based trust – laws, identity tokens, etc.
• Passports, drivers licenses
• Future is typically PKI oriented
 Federated enterprise-based; leverages one’s security
domain; often role-based
• Enterprise does authentication and attributes
• Federations of enterprises exchange assertions (identity and
attributes
 Peer to peer trust; ad hoc, small locus personal trust
• A large part of our non-networked lives
• New technology approaches to bring this into the electronic world.
• Distinguishing P2P apps arch from P2P trust
 Virtual organizations cross-stitch across one of the above
Federated administration
 Given the strong collaborations within the academic community,
there is an urgent need to create inter-realm tools, so
 Build consistent campus middleware infrastructure
deployments, with outward facing objectclasses, service points,
etc. and then
 Federate (multilateral) those enterprise deployments with
interrealm 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, from p2p to virtual organizations, etc. while we
 Be cautious about the limits of federations and look for
alternative fabrics where appropriate.
Federated administration
VO
VO
O
Apps CM
O
T
T
Campus 1
T
CM Apps
Campus 2
T
T
Federation
Other
feds
Federation considerations
 Federation update
• Federating software
• Bilateral and multilateral federations
• InCommon
Shibboleth Status
 Open source, privacy preserving federating software
 Being very widely deployed in US and international universities
 Target - works with Apache(1.3 and 2.0) and IIS targets; Java origins for a
variety of Unix platforms.
 V2.0 likely to include portal support, identity linking, non web services
(plumbing to GSSAPI,P2P, IM, video) etc.
 Work underway on intuitive graphical interfaces for the powerful underlying
Attribute Authority and resource protection
 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.)
 http://shibboleth.internet2.edu/
Shibboleth-based federations
 InQueue
 InCommon
 Club Shib
 Swiss Education and Research Network (SWITCH)
 National Science Digital Library (NSDL)
----------------------------------- State networks
 Medical networks
 Financial aid networks
 Life-long learning communities
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
InQueue
 The “holding pond”
 Is a persistent federation with “passing-through”
membership…
 Operational today. Can apply for membership via
http://shibboleth.internet2.edu/ InQueue Federation
guidelines
 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
InQueue Origins
2.12.04
Rutgers University
University of Wisconsin
New York University
Georgia State University
University of Washington
University of California Shibboleth Pilot
University at Buffalo
Dartmouth College
Michigan State University
Georgetown
Duke
The Ohio State University
UCLA
Internet2
Carnegie Mellon University
National Research Council of Canada
Columbia University
University of Virginia
University of California, San Diego
Brown University
University of Minnesota
Penn State University
Cal Poly Pomona
London School of Economics
University of North Carolina at Chapel Hill
University of Colorado at Boulder
UT Arlington
UTHSC-Houston
University of Michigan
University of Rochester
University of Southern California
Major targets
 Campuses that are also origins, wanting to share
campus-based content
 Content providers – EBSCO, OCLC, JSTOR, Elsevier,
Napster, etc
 Learning Management Systems – WebCT, Blackboard,
WebAssign, OKI, etc
 Outsourced Service Providers – purchasing systems,
dormitory management companies, locksmiths, etc.
InCommon federation
 A permanent federation for the R&E US sector
 Federation operations – Internet2
 Federating software – Shibboleth 1.1 and above
 Federation data schema - eduPerson200210 or later and
eduOrg200210 or later
 Becomes operational April 5, with several early entrants
to help shape the policy issues.
 Precursor federation, InQueue, has been in operation for
about six months and will feed into InCommon
 http://www.incommonfederation.org
InCommon Management
 Operational services by I2
• Member services
• Backroom (CA, WAYF service, etc.)
 Governance
• Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry Campbell (USC), Lev
Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy
Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC), David Yakimischak (JSTOR)
• Two Executive Committee working groups
– Policy – Tracy Mitrano, Chair
– Communications, Membership, Pricing and Packaging – Susan Perry, Chair
• Technical Advisory Group – Scott Cantor (OSU), Steven Carmody (Brown), Bob Morgan
(Washington), Renee Shuey (PSU)
• Project manager – Renee Frost (Internet2)
 Membership open to .edu and affiliated business partners
 Contractual and policy issues being defined now…
 Likely to take 501(c)3 status
Trust in InCommon - initial
 Members trust the federated operations to perform its
activities well
• The operator (Internet2) posts its procedures, attempts to execute
them faithfully, and makes no warranties
• Enterprises read the procedures and decide if they want to become
members
 Origins and targets trust each other bilaterally in out-ofband or no-band arrangements
• Origins trust targets dispose of attributes properly
• Targets trust origins to provide attributes accurately
• Risks and liabilities managed by end enterprises, in separate ways
InCommon Trust - ongoing
 Use trust  Build trust cycle
 Clearly need consensus levels of I/A
 Multiple levels of I/A for different needs
• Two factor for high-risk
• Distinctive requirements (campus in Bejing or France, distance ed,
mobility)
 Standardized data definitions unclear
 Audits unclear
 International issues
Balancing the work
 InCommon CA
• Identity proofing the enterprise
• Issuing the enterprise signing keys (primary and spare)
• Signing the metadata
 InCommon Federation
• Aggregating the metadata
• Supporting campuses in posting their policies
InC Ops 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_Referen
ce_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.
InCommon CA Ops
 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_compro
mise_ver_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_Federa
tion_System_Technical_Reference_ver_0.41
• Document describing the CA.
InCommon Key Signing Process
 2. Hardware descriptions
a. Hardware will be laptop and spare laptop with no network capabilities, thumb
drive, CDRW drive, media for necessary software
3. Software descriptions
a. OS, OpenSSL, CSP, Java tools for meta data
4. Log into computer
5. Generation of the CA Private Root key and self-signing
6. Generation of the Metadata signing key
7. Generate CSR for Internet2 origin
8. Signing of new metadata sites and trusts files
9. Backup copies of all private keys and other operational backup data are generated.
10. Verify CD's and MD5 checksum
11. Write down passphrase and put in envelopes and sign envelopes
12. Securely store CA hardware and contents of local safe in safe
13. Log that these actions occurred on the log in safe and then close and lock the safe
14. Put thumb drive into secure db and copy data onto secure db
15. Take private key password archive and other contents to Private Key Password
safe deposit box and record in log that this was done.
16. Take operational data archive to Operation Data safe deposit box and record in
log that this was done.
InCommon Ops Process Steps
 InCommon Process Technical Reviewers
•
•
•
•
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
• Witnessed
 Phase One participants vetting process and documentation
The potential for InCommon
 The federation as a networked trust facilitator
 Needs to scale in two fundamental ways
• Policy underpinnings need to move to normative levels among the
members; “post and read” is a starting place…
• Inter-federation issues need to be engineered; we are trying to align
structurally with emerging federal recommendations
 Needs to link with PKI and with federal and international
activities
 If it does scale and grow, it could become a most
significant component of cyberinfrastructure…
Beyond web services…
 Federated security services
• Collaborative incident correlation and analysis
• Trust-mediated transparency and other security-aware capabilities
 Federated extensions to other architectures
• Lionshare project for P2P file sharing
• IM
• Federated Grids
Virtual organizations
 Need a model to support a wide variety of use cases
• Native v.o. infrastructure capabilities, differences in enterprise
readiness, etc.
• Variations in collaboration modalities
• Requirements of v.o.’s for authz, range of disciplines, etc
 JISC in the UK has lead; solicitation (see
(http://www.jisc.ac.uk/c01_04.html); builds on NSF NMI
 Tool set likely to include seamless listproc, web sharing,
shared calendaring, real-time video, privilege
management system, etc.
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 (Internet2); Michael
Gettes (Duke), Scott Fullerton (Madison)
 Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU),
Walter Hoehn (Columbia/U of Memphis)
For More Information
 NSF Middleware Initiative-sponsored “Shibboleth CAMP” in
June
• Expect 120-150 attendees
• First day features an Install Fest….
 http://middleware.internet2.edu
 http://shibboleth.internet2.edu
 http:/www.incommonfederation.org
Renee Woodten Frost rwfrost@internet2.edu