Shibb oleth: Building Tools for Inter-institutional Resource Sharing InCommon: A Shibboleth-based Research and Education Federation Renee Woodten Frost.

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

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”

[email protected]

EPPN

(eduPersonPrincipalName)

Identity [email protected]

Entitlement An agreed upon opaque URI urn:mace:vendor:contract1234

OrgUnit Department Economics Department

EnrolledCourse Opaque course identifier urn:mace:osu.edu:Physics201

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 2000OpenSAML release – July 2002Shib v1.0 April 2003Shib v1.1 July 2003Shib v1.2 April 2004; Shib v1.2.1 November 2004Shib v1.3 1Q05 – non web services, e-Auth certifiedShib v1.4 WS-Fed compliantOpenSAML 2.0 – relatively soonShib 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 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

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

5 Feb 2005

Some InQueue Credential Providers

Brown UniversityCal Poly Pomona Carnegie Mellon UniversityColumbia UniversityCornell University Dartmouth College Duke UniversityGeorgetown UniversityGeorgia State UniversityInternet2London School of EconomicsMichigan State UniversityNational Research Council of CanadaNew York UniversityPenn State UniversityRutgers UniversityThe Ohio State UniversityThe University of Kansas

University of Alaska FairbanksUniversity of ArkansasUniversity of BristolUniversity of BuffaloUCLA University of California, San DiegoUniversity of California Shibboleth PilotUniversity of Colorado at Boulder University of MichiganUniversity of MinnesotaUniversity of Missouri - ColumbiaUniversity of North Carolina at Chapel HillUniversity of RochesterUniversity of South DakotaUniversity of Southern California UT ArlingtonUTHSC-HoustonUniversity of VirginiaUniversity of Wisconsin

5 Feb 2005

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 no-band 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_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.

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, presenceHandling international resource-providersQualifying new membersRelationship to other sector activities, particularly

government (and health services)Support for virtual organizationsPromoting its use for applications: eduRoam, GLIF, GridsEU Privacy issues International WAYFUniversal 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 [email protected]