InCommon UpdateInternet2 Meeting

April 20, 2004

Ken Klingenstein and

Carrie Regenstein

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 object classes, 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

O

TO

T

T T

A CMCM A

VOVO

T

Campus 1Campus 2

Federation

Virtual Organizations

Geographically distributed, enterprise distributed community that shares real resources as an organization.Examples include team science (NEESGrid, HEP, BIRN, NEON), digital content managers (library cataloguers, curators, etc), life-long learning consortia, etc.On a continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers)Want to leverage enterprise middleware and external trust fabrics

Leveraging V.O.s Today

VO

Target Resource

User

Enterprise

Federation

Leveraged V.O.s Tomorrow

VO

Target Resource

User

Enterprise

Federation

Collaborative Tools Authority Systemetc

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

Why a Federation for the Academic Community?

Scenario #1: Instruction• Professor teaches at USC, which has enrolled students from

CMU, through an inter-institutional cooperative agreement of universities (aka “origins”).

• During scheduled office hours, the professor works at her workstation, when a pop-up box appears that John Doe from CMU is requesting to initiate a videoconference with her.

• Info is also conveyed that CMU asserts that this is, in fact, who he claims to be and further, is an enrolled student in the class.

• She can make an informed decision about whether to accept the videoconference invitation.

• The info is believed because it has been delivered in the context of a trusted federation.

Why a Federation for the Academic Community?

Scenario #2: Research• A group of researchers, spread across a number of

member institutions of the federation, want to securely share a web site located on one of the campuses. Each researcher can use his or her own campus identity and login to access the restricted site. Confidence is based on the fact that the institutions belong to a trusted federation.

Why a Federation for the Academic Community?

Scenario #3: Living and learning• A content provider (aka “target”) wants to change

from IP access controls to better technologies for gating content to an institutional customer, and is therefore willing to accept campus credentials for access to content. This provides better security and enables higher levels of granularity in controlling access if restricted access is desired. The basis for the content provider trusting in the origin is the trusted federation.

What is InCommon?

InCommon is…• a formal federation of organizations focused on creating a

common framework for trust in support of research and education…

• whose purpose is to facilitate collaboration through the sharing of protected resources, by means of an agreed-upon, common trust fabric.

The InCommon federation is intended to support production-level end-user access to protected resources by providing the means to allow organizations to make effective decisions about sharing resources, based upon the attributes presented by a request user.

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

InCommon Federation Overview

Federation operations – Internet2 Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and

eduOrg200210 or later Becomes operational April 2004, 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://incommon.internet2.edu

InCommon Management

Operational services by I2• Member services • Backroom (CA, WAYF service, etc.)

Governance • Executive Committee - Carrie Regenstein - chair (Wisconsin-

Madison), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR).

• Project manager – Renée Frost (Internet2) Membership open to .edu and affiliated business partners (Elsevier,

OCLC, Napster, Diebold, etc…) Contractual and policy issues being defined now… Likely to take 501(c)3 status

InCommon Pilot

Phase One participants• Cornell, Dartmouth, Penn State, SUNY-Buffalo, University of

Rochester, USC, UT-Health Science Center-Houston, UVa, JSTOR, OCLC

Exec Group’s Policy Sub-Committee (Tracy Mitrano, chair)• Drafting evolutionary policies and procedures for members of

federation.• Considering other policy frameworks, e.g., EDUCAUSE Higher

Ed Bridge Cert Authority (HEBCA), I2’s US Higher Ed Root (USHER) Cert Authority, etc.

Exec Group’s Communications, Membership, Pricing and Packaging Sub-Committee (Susan Perry, chair)

• Who can join? How?• Getting the word out … in English

Getting to first base

Alphonse-Gaston: establishing a set of rules to determine criteria for InCommon membership

• Individual members may not want to know the details about other members’ policies. Do they need to?

• Members of the federation use different assumptions, e.g, some University Systems may want to join as a collective system, while others would prefer to join as individual campuses. Is consistency important?

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

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

Developing an inventory of campus identifiers

What assertions are acceptable for what purposes?

Risk and trust requirements will be determined by the resource holder as well as the user considering their personal privacy risk. Taken together, these requirements will determine the technologies and policies implemented.

• At the low risk & low trust end of the continuum: public information websites, videoconferencing meeting for the Shib Development Team.

– What assertions— if any — should be required?

• At the mid-level of risk and trust: access to copyrighted materials, course management systems, business services, etc.

• At the high risk & high trust end of the continuum: access to medical records, data from a bio-terrorism lab, videoconferencing meeting of security experts discussing response to network security emergency.

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

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…

Authenticate locally, Act federally

For general information• http://internet2.edu

For membership information • incommon-info@internet2.edu