1 Update on the InCommon Federation, Higher Education’s Community of Trust EDUCAUSE 2005 October 19 10:30am-11:20am

2 Introductions Carrie E. Regenstein, Executive Director for Computing Services, Carnegie Mellon University Susan Perry, Senior Advisor, The Andrew W. Mellon Foundation, Director of Programs, Council on Library and Information Resources –John Krienke, Internet2 (David L. Wasley, Infrastructure Planner (retired), University of California Office of the President) And attendees: Who’s here?

3

4 Why a Federation for the Academic Community? Scenario #1: Instruction –History professor at Cornell who wants to partner with a NYU professor in an urban history class. –Both professors have digital materials for this class that they want to use to compare and contrast. –Eighty students, two professors and two teaching assistants who want to move seamlessly between each of the institutions and among all of the materials for the course. –Must have authenticated services, but do not want nor have the authority to give network identifiers for each institution –They access their own campus login, and authorization information is passed to servers in each institution –The info is believed because it has been delivered securely in the context of a trusted federation.

5 Why a Federation for the Academic Community? Scenario #2: Research –International team, doing earthquake simulation, made up of researchers from Australian National University, USC, and Kyoto. –All three members require access to research data owned by the Southern California Earthquake Center stored at USC *and* the High Performance Computing Center (HPCC) at USC. –Each researcher can use his or her own campus identity and login to access the restricted site. –Confidence is based on the exchanged attributes for authorization and that the institutions belong to a trusted federation.

6 Why a Federation for the Academic Community? Scenario #3: Learning Partnerships –A regional library system wants to change from IP- access controls to better technologies for gating content to an institutional customer –The library is willing to accept campus logins for access to content. –Campuses can protect their students’ privacy to resource providers by sharing only the information that a requesting user is an actively enrolled student. –For more options in controlling access, specific attributes could be shared if the campus agrees: “freshman,” “biology student,” “BIO101 student,” etc. –The basis for the regional library system trusting the campus is the trusted federation.

7 Why a Federation for the Academic Community? Scenario #4: eCommerce –In order to encourage and facilitate legal music downloading, a university contracts with a digital music provider. –The music resource provides a single, standards- based federated authorization platform for all participating institutions –The campus, required to protect its students’ privacy, agrees to pass only “active student” status information about each user to the resource provider –Students successfully download legal music, and the resource partner is secure in the trustworthiness of its customer base because of the InCommon trust foundation

8 Other Uses Institutional users acquiring content from popular providers (Napster) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.) from off campus Institutions working with outsourced service providers, e.g. grading services, scheduling systems, LMS (WebAssign, Blackboard, etc.) Inter-institutional collaborations, including groupware, interactive messaging, research computing sharing, etc. Shared network security monitoring Wireless access for visitors from peer institutions Federal Gov’t resources and administration (financial aid, grant submissions, etc.)

9 Identity Federation A group of cooperating identity-service providers and resource providers sharing in the task of providing “identity services” in support of service access management for their communities The Federation: –Defines policy, rules and requirements for participation –Defines common vocabulary for identity attributes –Operates common services required for interoperability –Helps resolve problems and disputes –May assess and/or audit participants

10 InCommon makes sharing protected online resources easier InCommon is… –a formal federation of organizations creating a common framework for trusted identity 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 enables higher education organizations and their partners to make effective decisions about sharing resources based upon identity attributes presented by a requester Risk mitigation and Trust requirements between resource providers and identity providers will drive technology and policies

11 InCommon Trust Fabric InCommon verifies the identity of all participating organizations and issues server certificates for secure communication Participants agree to the Federation operational principles and share among themselves their own resource and identity management operational principles Each resource manages access based on the agreed-upon user identity attributes Each home organization manages user accounts and the release of personal information (identity and privacy management)

12 Without InCommon

13 With InCommon - The Home organization manages accounts and the release of needed personal information

14 Demonstration Introducing John Krienke, Operations Manager for the InCommon Federation

15 InCommon Participants Two types of participants: –Higher Ed institutions: 2 or more year, post-secondary, accredited as recognized by the Federal Dept. of Ed. –Sponsored partners: partners sponsored by Higher Ed institutions, e.g. library systems, publishers, media providers, other service providers Participants can function in both roles of identity providers and resource providers –Higher Ed institutions are identity providers that also may provide resources and services –Sponsored Partners primarily offer resources and services, but can serve as identity providers as well

16 InCommon Principles Support the research and education 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 for identity management, privacy, etc InCommon will assist its participants in moving to higher levels of identity assurance as applications warrant InCommon will work closely with other national and international federations

17 The InCommon Federation Governed by a Steering Committee –Both Higher Ed and Sponsored Partners Operations Unit –Registers Participants Verifies institution’s eligibility and representatives –Issues Participant server IDs and credentials –Securely collects and redistributes metadata –Provides documentation, help desk, and technical support

18 InCommon Governance Steering Committee –Carrie Regenstein, Carnegie Mellon University - Chair –Tracy Mitrano, Cornell - Vice Chair –Jerry Campbell, University of Southern California - Treasurer –Clair Goldsmith, University of Texas System - Secretary –Mike Teets, OCLC - Assistant Secretary –Lev Gonick, Case Western Reserve –Mark Luker, Educause –Susan Perry, Mellon Foundation –Ken Klingenstein, Internet2 Advisors –Renee Frost, Internet2 –David Wasley, UCOP, retired Operations –John Krienke, Internet2

19 Prerequisites Official University Directory –Deploying a single, unique electronic identifier Web-based login system using campus ID Middleware: Implementing Technology –Identity management system –InCommon identity attributes –Campus supported IT framework with focus on security and privacy policies –Federating software (Shibboleth)

20 InCommon Pricing Goals –Cost recovery –Scalable as InCommon grows Prices –Application Fee: $700 (largely enterprise I&A) –Annual Fee Higher Ed Participant: $1000 per identity management system Sponsored Participant: $1000 per identity management system

21 InCommon, Today and Tomorrow Established participants (23 and growing): Work in progress –Multi-layered strength-of-trust threads among participants –Peering with national federations in other countries, with other state federations, with commercial federations Case Western Reserve UniversityCornell UniversityDartmouth Elsevier Science DirectGeorgetown UniversityInternet2 Houston Academy of Medicine - Texas Medical Center Library OhioLink - The Ohio Library & Information Network OCLC Ohio UniversityOhio State UniversityPenn State SUNY BuffaloThe University of ChicagoUniversity of California, Irvine University of California, Los Angeles University of California, Office of the President University of California, San Diego University of RochesterUniversity of Southern CaliforniaUniversity of Virginia University of WashingtonWebAssign

22 The Potential for InCommon The federation as a networked trust facilitator Needs to scale in two fundamental ways –Policy underpinnings need to evolve 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 state, regional, federal, and international activities (e.g., for activities such as grant submissions and financial aid) If it does scale and grow, it could become a most significant component of cyberinfrastructure…

23

24 Shibboleth Attribute-Based Authorization Resource WAYF Identity Provider Resource Provider Website 1 ACS I don’t know you or your home organization. I redirect your request to the InCommon WAYF 3 2 Where are you from? HS 5 6 I don’t know you. Please authenticate Using your Web login 7 User DB ID+Password OK, I know you now. I redirect your request to the Resource, along with a handle 4 OK, I will now redirect your request to your home org. AR Handle 8 I don’t know the attributes of this user. Let’s ask the Attribute Authority Handle 9 AA I trust you. I’ll pass the attributes the user has allowed me to release Attributes 10 Resource Manager Attributes OK, based on the attributes, I grant access to the resource © Switch user initiates a request

25