1. Shibboleth: Federated Identity Management
Renee Woodten Frost,
Internet2 Middleware and Security
17 May 2004

2. Copyright Renee Woodten Frost 2004
Copyright Renee Woodten Frost This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
17 May 2004

3. A Word from the Sponsors: Internet2 and NSF
HE consortium partnering with government and industry
Advanced Network Technologies
NSF Middleware Initiative (NMI)
Analogous to building the NSFnet
Scientists and engineers can transparently use and share distributed resources, such as computers, data, and instruments
Research and education communities can effectively collaborate using advanced communications tools
Internet users around the world can benefit.
17 May 2004

4. Agenda What is Shibboleth? What is its Current Status? Why Shibboleth?
Who is Using Shibboleth?
Federations
InQueue
InCommon
For more information
17 May 2004

5. 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)
17 May 2004

6. 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 Origins (campuses)
Software for Targets (service providers)
Operational Federations (scalable trust)
17 May 2004

7. 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
17 May 2004

8. 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.
17 May 2004

9. Typical Attributes in the Higher Ed Community
Affiliation
“active member of community”
EPPN
Identity
Entitlement
An agreed upon opaque URI
urn:mace:vendor:contract1234
OrgUnit
Department
Economics Department
EnrolledCourse
Opaque course identifier
urn:mace:osu.edu:Physics201
17 May 2004

10. Stage 1 - Addressing Four Scenarios
Member of campus community accessing licensed resource
Anonymity required
Member of a course accessing remotely controlled resource
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.
17 May 2004

11. 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?
17 May 2004

12. Shibboleth Architecture (still photo, no moving parts)
17 May 2004

13. Shibboleth Status Software Availability Campus Adoption accelerating…
Version 1.1 available August, 2003
Version 1.2 available May, 2004
Version 1.3 available Summer, 2004
Campus Adoption accelerating…
Working with increasing number of information/service providers
Java target implementation underway
Work underway on some of the essential management tools such as attribute release managers, target resource management, etc.
17 May 2004

14. 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.
UK’s JISC awards just announced for Core Middleware: Technology Development Programme
Used by several federations today – NSDL, InQueue, SWITCH and several more soon (UK, Australia, Finland, etc.)
17 May 2004

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

16. 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
17 May 2004

17. Why Shibboleth? Federated Administration
Flexibly partitions responsibility, policy, technology, and trust
Leverages existing middleware infrastructure at origin - authentication, 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
17 May 2004

18. 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”
17 May 2004

19. 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
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
17 May 2004

20. 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 universities have Shibboleth implemented already, easy implementation for them
17 May 2004

21. 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
17 May 2004

22. 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
17 May 2004

23. 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 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, from p2p to virtual organizations, etc. while we
Be cautious about the limits of federations and look for alternative fabrics where appropriate.
17 May 2004

24. Federated AdministrationVO VO O T
Apps CM O T
CM Apps
Other
feds
Campus 1
Campus 2 T T T
Federation
17 May 2004

25. 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
17 May 2004

26. The Research and Education Federation Space
REF
Cluster
InQueue
(a starting point)
InCommon
SWITCH
The Shib
Research Club
Other national nets
Other clusters
Other
potential US
R+E feds
State of Penn
Fin Aid Assoc
NSDL
Indiana
Slippery slope
- Med Centers, etc
17 May 2004

27. InQueue The “holding pond”
Is a persistent federation with “passing-through” membership…
Operational today. Can apply for membership via 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: cost-recovery basis
17 May 2004

28. InQueue Origins 2.12.04 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
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
17 May 2004

29. 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.
17 May 2004

30. InCommon Federation A permanent federation for the R&E US sector
Federation operations – Internet2
Federating software – Shibboleth 1.1 and above
Federation data schema - eduPerson or later and eduOrg or later
Became 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
17 May 2004

31. InCommon Management Operational services by I2 Governance
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
17 May 2004

32. 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-of-band 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
17 May 2004

33. 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
17 May 2004

34. Balancing the Work InCommon CA InCommon Federation
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
17 May 2004

35. InCommon 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.
17 May 2004

36. InCommon 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_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_Federation_System_Technical_Reference_ver_0.41
Document describing the CA.
17 May 2004

37. 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 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 Take operational data archive to Operation Data safe deposit box and record in log that this was done.
17 May 2004

38. InCommon Operations 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
17 May 2004

39. 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…
17 May 2004

40. 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
17 May 2004

41. Virtual Organizations (VOs)
Need a model to support a wide variety of use cases
Native VO infrastructure capabilities, differences in enterprise readiness, etc.
Variations in collaboration modalities
Requirements of VOs for authorization, range of disciplines, etc
JISC in the UK has lead; solicitation (see ( builds on NSF NMI
Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.
17 May 2004

42. 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)
17 May 2004

43. For More Information NSF Middleware Initiative-sponsored workshop:
“CAMP Shibboleth”
June in Broomfield, Colorado
Features a Shib Install Fest
Websites
Renee Woodten Frost
17 May 2004