24 Jun 2004

Shibboleth: Building Tools for Inter-institutional

Resource Sharing

Renee Woodten Frost

Internet2 Middleware and Security

24 Jun 2004

Topics

Middleware Background What is Shibboleth? What is its Current Status? Why Shibboleth? Who is Using Shibboleth? Federations

• InQueue• InCommon

For more information

24 Jun 2004

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

24 Jun 2004

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

24 Jun 2004

A Map of Campus Middleware Land

24 Jun 2004

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), Bruce Vincent (Stanford), David Wasley (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...

24 Jun 2004

Internet2 Middleware and the NSF Middleware Initiative (NMI)

Internet2 Middleware a major theme for the last five years, drawing support from 206 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 (ala Grids)

• Common campus and inter-institutional middleware infrastructure (ala Internet2/EDUCAUSE/SURA work)

Issues periodic NMI releases of software, services, architectures, objectclasses and best practices – R5 most current release

24 Jun 2004

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 the 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.

24 Jun 2004

Middleware Axioms

Work the core areas

Focus on support for collaboration

Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions

Develop a consistent directory infrastructure within R&E

Provide security while not degrading privacy.

Foster inter-realm trust fabrics: federations and virtual organizations

Leverage campus expertise and build rough consensus

Support for heterogeneity and open standards

Influence the marketplace; develop where necessary

24 Jun 2004

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)

24 Jun 2004

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 (credential providers = campuses)• Software for Targets (service providers)• Operational Federations (scalable trust)

24 Jun 2004

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

24 Jun 2004

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.

24 Jun 2004

Typical Attributes in the Higher Ed Community

Affiliation “active member of community”

member@washington.edu

EPPN

(eduPersonPrincipalName)

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

24 Jun 2004

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.

24 Jun 2004

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?

24 Jun 2004

Shibboleth Architecture (still photo, no moving parts)

24 Jun 2004

Development Milestones

Project formation - Feb 2000 Stone Soup; process began late summer 2000 with bi-weekly calls to develop scenarios, requirements and architecture.

Linkages to SAML established Dec 2000

Architecture and protocol completion - Aug 2001

Design - Oct 2001

Coding began - Nov 2001

Alpha-1 release – April 24, 2002

OpenSAML release – July 15, 2002

v1.0 April 2003; v1.1 July 2003; v1.2 May 2004, v1.3 summer

v2.0 likely end of the major evolution

24 Jun 2004

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, target resource management, etc.

Needs federations to scale; being adopted by, or catalyzing, national R&E federations in several countries

24 Jun 2004

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 – 8 of 15 involve Shib

Used by several federations today – NSDL, InQueue, SWITCH and several more soon (UK, Australia, Finland, etc.)

24 Jun 2004

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 Integration with Grids, Virtual Organizations Integration with Saml V2.0, Liberty Alliance, WS-Fed NSF grant to Shibboleth-enable open source collaboration

tools LionShare - Federated P2P

24 Jun 2004

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

24 Jun 2004

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

24 Jun 2004

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”

24 Jun 2004

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

24 Jun 2004

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 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

24 Jun 2004

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

24 Jun 2004

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 & 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

24 Jun 2004

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.

24 Jun 2004

Federated Administration

O

TO

T

T T

Apps CMCM Apps

VOVO

T

Campus 1Campus 2

Federation

Otherfeds

24 Jun 2004

Shibboleth-based Federations

InQueue InCommonClub ShibSwiss Education and Research Network (SWITCH)National Science Digital Library (NSDL)

------------------------------------State networksMedical networksFinancial aid networksLife-long learning communities

24 Jun 2004

The Research and EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clustersOther

potential USR+E feds

State of Penn Fin Aid Assoc

NSDL

Slippery slope- Med Centers, etc

Indiana

24 Jun 2004

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: cost-recovery basis

24 Jun 2004

InQueue Origins2.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 CanadaColumbia UniversityUniversity of VirginiaUniversity of California, San DiegoBrown UniversityUniversity of MinnesotaPenn State UniversityCal Poly PomonaLondon School of EconomicsUniversity of North Carolina at Chapel HillUniversity of Colorado at BoulderUT ArlingtonUTHSC-HoustonUniversity of MichiganUniversity of RochesterUniversity of Southern California

24 Jun 2004

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.

24 Jun 2004

InCommon Federation

A permanent federation for the R&E US sectorFederation operations – Internet2Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and

eduOrg200210 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 http://www.incommonfederation.org

24 Jun 2004

InCommon Management

Operational services by Internet2• Member services • Backroom (Certificate Authority, 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)

Initially an LLC and likely to take 501(c)3 status

24 Jun 2004

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

24 Jun 2004

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

24 Jun 2004

Balancing the Operator’s Trust Load

InCommon Certificate Authority (CA)• Identity proofing the enterprise• Issuing the enterprise signing keys (primary and spare)• Signing the metadata• Could be outsourced

InCommon Federation• Aggregating the metadata• Supporting campuses in posting their policies• Less easy to outsource

24 Jun 2004

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.

24 Jun 2004

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.

24 Jun 2004

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.

24 Jun 2004

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

24 Jun 2004

InCommon Startup

Membership: open to .edu-qualified sites and business partners

Policy, Practices, Pricing, Packaging to be developed by Exec Comm working groups and phase one participants

Privacy requirements to be developed:• May be = destroy received attributes immediately upon use

Security requirements to be developed:• May be = enterprises post local I/A and basic business rules for

assignment of eduPersonAffiliation values• Likely to progress towards standardized levels of authentication • Logout issues

24 Jun 2004

Phase One Rollout

11 organizations

Requests to add more – 4 institutions, 2 service providers

Feedback on process and documents

Federation Operating Rules drafted

Participant Agreement drafted/under review

Participant Operational Practice Statement developed/being vetted by phase one participants

Pricing and Packaging model drafted/proposals being discussed/vetted

24 Jun 2004

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…

24 Jun 2004

Acknowledgements

Design Team: David Wasley (U of C); RL ‘Bob’ Morgan (Washington); Keith Hazelton (Wisconsin - Madison); Marlena Erdos (IBM/Tivoli);

Steven Carmody (Brown); Scott Cantor (Ohio State)

Important Contributions from: Ken Klingenstein (Internet2); Michael Gettes (Duke), Scott Fullerton (Wisconsin - Madison)

Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU), Walter Hoehn (Columbia/U of Memphis)

24 Jun 2004

For More Information

NSF Middleware Initiative-sponsored workshop:

“CAMP Shibboleth”• June 28-30 in Broomfield, Colorado

• Features a Shib Install Fest

Websites

http://middleware.internet2.edu

http://shibboleth.internet2.edu

http:/www.incommonfederation.org

Renee Woodten Frost rwfrost@internet2.edu