1 the incommon federation, higher education’s community of trust: why join and how to do it...
TRANSCRIPT
1
The InCommon Federation,Higher Education’s Community of
Trust: Why join and how to do it
EDUCAUSE 2005Pre-Conference Seminar
October 188:30am-Noon
2
Presenters
• 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
• David L. Wasley, Infrastructure Planner (retired), University of California Office of the President
• John Krienke, Operations Manager, InCommon, Manager Integrated Operations, Internet2
3
Agenda
1. Introductions
2. The value of InCommon
3. Underpinnings of technology and trust
4. Demonstrations
5. Operations and how to join
6. Summing up and future steps
4
1. Introductions
Your turn
5
2. The Value of InCommon
Inter-institutional Scholarly Communityand
Campus Identity Management
6
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
7
InCommon
The InCommon federation enables Higher Education institutions and their partners to share resources in a trusted, standardized fashion that protects privacy, respects copyright, and fosters collaboration and innovation.
How? Authorization to a protected resource or service is based in
part on the InCommon Federation’s trust fabric.– Organizations are identified and authenticated by InCommon as
a trusted participant– Users log in and authenticate their identity with their home
organization– Agreed upon user attributes are sent securely to the resource,
which then makes an access decision
8
Without InCommon
9
With InCommon
- The Home organization manages accounts and the release of needed personal information
10
InCommon Trust Fabric• InCommon verifies the identity of all participating
organizations and issues server certificates for secure communication
• Participants agree to the Federation operational principals and share among themselves their own resource and identity management operational principals
• 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)
11
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.
12
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.
13
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.
14
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
15
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 [stuff deleted]• Wireless access for visitors from peer institutions• Federal Government resources and administration
(financial aid, grant submissions, etc.)
16
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 to others– Sponsored Partners primarily offer resources and
services, but can serve as identity providers as well
17
InCommon 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 for identity management, privacy, etc
• InCommon will assist its participants in moving to higher levels of assurance as applications warrant
• InCommon will work closely with other national and international federations
18
Shibboleth Attribute-Based Authorization
Res
ou
rce
WAYF
Identity ProviderResource Provider
Website
1
ACS
I don’t know you or your home organization.I redirect your request
to the InCommonWAYF3
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 requestto the Resource, along
with a handle
4
OK, I will nowredirect your
request toyour home org.
AR
Handle
Handle8
I don’t know theattributes of this user.Let’s ask the Attribute
Authority
Handle9AA
I trust you.I’ll pass the
attributes the userhas allowed me to
release
Attributes 10
Res
ou
rce
Man
ag
er
Attributes
OK, based on theattributes, I grant
access to the resource
© Switch
user
initiates a request
19
Ah, hah!
• “I think the value proposition of InCommon for my institution is …”
20
3. InCommon ID Management Architecture
Technology and Trust
21
22
In Identity We Trust
• On-line Resource Providers trust Identity Providers to assert accurate and trustworthy identity information
• Identity Service Providers trust Resource Providers to make only appropriate use of identity information they are given
• Subjects trust both Identity Service Providers and Resource Providers to protect and not abuse personal information
23
Agenda
• Campus as ID Service Provider– Common Identity model– Credentials & Directories– Privacy– Levels of assurance
• External use of campus ID– Shared identity management federations– Shibboleth and InCommon– Federations of federations
24
Campus as ID Service Provider• Campus already provides ID cards, keys, etc.• Many on-line systems have “accounts”• ID management can be extracted as a
comprehensive service supporting a wide range of campus services
• Should be part of the business structure– Fundamental to most (all?) IT-based systems– Managed under policies, rules, etc.– Trusted by most campus services
25
Common Identity Model
• Useful to view identity in a common way:– Identity is the information associated with a
given Subject (person or other entity)– The Subject is issued a means by which to
assert association with that information– Services and applications can verify that
assertion and acquire needed information
Subject Token Information AccessManagement
26
Subject Credentials
• UserID/passwd, smartcard, PKI cert, etc.– Each has pros and cons
• Credentials issued by a responsible authority must:– Verify Subject’s association with existing info.– Use appropriate credential technology– Ensure only the Subject gets the credential– Be revoked when necessary
• Credential may contain static ID information
27
Identity Directories/Databases
• Hold authoritative info. WRT Subject– E.g. Name, UID#, affiliation, contact, roles, etc.
• Sources are Offices of Record, e.g., Registrar– Relational DB can distribute management
• Information must be managed well– It’s at least as important as the credential !!
PersonData
RegistrarData
Human ResourcesData
Credential
28
Privacy and Security
• Identity databases incur several serious responsibilities– Protection against unauthorized access– Release of only necessary information to
appropriate parties– Allow the Subject to express release policy
• Subject may deny themselves access to services• May help campus conform to FERPA
• Databases must be managed securely
29
Levels of Assurance
• Trustworthiness of identity assertions– How reliable is the credential technology?– How was it issued and managed?– How authoritative is the identity information?– How well is it maintained and managed?– How is the source identified to the recipient?
• Trustworthiness of receiving parties– How is the recipient identified to the source?– What will the recipient do with the information?
30
Internal Campus Use of IDs
• Identity Management System must be reliable enough for the campus uses to which such IDs will be put
• Different Subjects may have differently trustworthy credentials
• All the above is under control of campus policy and business rules
• Implementation will be evolutionary
31
External Use of Campus ID
• External parties may be willing to accept campus ID assertions if risks are acceptable
• Examples include licensed library resources (low risk), external grant processes (moderate risk), e-commerce (higher risk)– All the above require bilateral agreements
• Campus IdM practices are key– but what party asserts the Level of Assurance?
• Campus also must assess risks ...
32
Shared Identity Management Federations
• “Shared” means a group of cooperating ID service providers and resource providers share in the task of providing “identity services” in support of access management for the full joint set of their communities and users
• The Federation must:– Define the terms and conditions for participation– Define the common basic identity vocabulary– Define the technical standards for interoperability
• The Federation may also assess LOA for ID providers and on-line resource providers
33
InCommon and Shibboleth
• The InCommon Federation– Defines Eligibility and Participation Agreement
• Does not define required IdM practices
– Defines a subset of eduPerson that is required of all ID service providers
– Defines Shibboleth versions with which participants must be compatible
• InCommon may adopt levels of assurance and an assessment process
34
The InCommon Federation
• Governed by a Steering Committee– Both Higher Ed. and Sponsored Partners
• Operations Unit– Registers Participants (identity verification)
and issues Participant credentials– Securely collects and redistributes metadata– Provides documentation, help desk, and
technical support
35
Federations of Federations
• InCommon serves U.S. Higher Education and related Sponsored Partners
• Many other federations are emerging– European R&E communities– Canada, Australia, China, ...– Commercial entities– Federal eAuthentication
• Inter-federation interoperability extends the trust model and requires a more active role of Federation governance– Being pursued by InCommon and eAuth
36
‘In Unity there is Access’
Putting all this together, we are moving towards a model where “identity service providers” will be able to provide trusted and appropriate information to a wide range of on-line services and resources.
This can enable seamless construction of rich networked environments in support of education, research, business, ...
37
4. Demos
John Krienke
Manager, InCommon Operations
38
5. Operations and How to Join
39
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
40
InCommon Operations
• InCommon CA (Certificate Authority)– Identity proof participating organizations and trusted
individuals – Issue the participant signing keys– Sign the participant metadata
• InCommon Federation– Aggregate the metadata– Support campuses in posting their policies– Peer with other national and international federations– Technical help and problem resolution
41
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
• All Participants: 20 ResourceProvider IDs included; additional bundles of 20 ResourceProvider IDs available at $1000 per year
42
Prerequisites
• Official University Directory– Deploying a single, unique electronic identifier– Supporting basic eduPerson attributes
• Web-based authentication system– can use a variety of credential technologies– can be a ‘single sign-on’ system
• Middleware: Implementing Technology– Identity management system– Supported by campus business, security and privacy
policies – Federating software (Shibboleth)
43
6. Summing Up andFuture Steps
44
InCommon, Today and Tomorrow
• Established today with 23+ Participants
• Will scale to several hundred Participants
• Developing multi-layered “level of assurance” threads among Participants
• Working with state and/or regional federations
• Planning to peer with national federations in other countries, with other state Federal federations, with commercial federations
45
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 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…
46
Your Perspective
• What is your institution’s perspective on identity management, federated access to resources, collaboration technologies, and trusted exchange for research and education?
47
Related Sessions
• Update on the InCommon Federation, the Higher Education Community of Trust– Wednesday, 10:30 a.m. - 11:20 a.m.
Meeting Room W110A • From Bright Idea to Concrete Implementation: The
Identity Management Life Cycle for Consortia– Wednesday, 11:40 a.m. - 12:30 p.m.
Meeting Room W110A • Identity Management in Action: How Campuses Are
Using Shibboleth to Solve Today's Access Problems– Friday, 8:10 a.m. - 9:00 a.m.
Meeting Room W206A
48
www.incommonfederation.org
49
Bios
50
Carrie E. Regenstein• Carrie E. Regenstein became the Executive Director for Computing
Services at Carnegie Mellon University in September 2005. Prior to that she served as Associate CIO and Associate Director of DoIT (Division of Information Technology) at the University of Wisconsin-Madison. Between 1998 and 2001, Carrie served as Director of Academic Technology Services (a unit of Information Technology Services) and Assistant Dean for Educational Technology for The College at the University of Rochester, following many years of leading academic technology initiatives at Cornell University. Carrie is a member of the Institute of Computing Policy and Law Advisory Board, sponsored by EDUCAUSE and Cornell University; and co-chairs Internet2’s InCommon Executive Steering Committee (http://www.incommonfederation.org/). With Barbara Dewey, she co-edited a collection of essays by Frye Institute ’00 participants: “Leadership, Higher Education, and the Information Age: A New Era for Information Technology and Libraries” (http://www.neal-schuman.com/).
51
Susan Perry• Susan Perry is a senior adviser to the Andrew W. Mellon
Foundation, working with the National Institute for Technology and Liberal Education to help Mellon-supported liberal arts colleges with issues regarding teaching and learning with technology. She is also director of programs for the Council on Library and Information Resources. Previously she was director of Library, Information and Technology Services at Mount Holyoke College. She also held leadership positions in libraries and computing at Stanford University and The Evergreen State College. Her information management experience covers libraries, academic computing, administrative computing and media services. Perry serves on the Board of Directors of EDUCAUSE and the Steering Committee for the Coalition for Networked Information. She received an undergraduate degree in history from Wake Forest University and a MS degree in Library Science from the University of North Carolina, Chapel Hill.
52
David L. Wasley• David L. Wasley was a Special Assistant to the Associate Vice
President, Information Resources and Communications, at the University of California Office of the President. Mr. Wasley's work focused on information infrastructure planning broadly across the university. Mr. Wasley has been active in forums that promote development of national and international network based systems for education and research communities. These activities have included development, planning, and implementation of Internet2 and the California CalREN-2 network. Mr. Wasley currently is active in national working groups developing strategies for deployment of middleware services such as strong digital credentials and federated identity for management of access to distributed resources. Mr. Wasley has written about Internet-based "middleware" as the foundation of next generation institutional technology.
53
John C.W. Krienke• John Krienke, Manager of Integrated Operations at Internet2,
oversees a variety of services and projects, including the InCommon Federation, Internet2’s Meeting Services, and other projects in the wings that are on track to becoming viable services.
Prior to joining Internet2, John worked at Boston's WGBH Educational Foundation in the Descriptive Video Service where he wrote, produced, and directed accessible versions of films and television programs for blind and visually impaired audiences and lead the editorial team as Post-Production Director. He was also a producer at educational resource websites, including the Learning Network and the Fathom consortium.
54
www.incommonfederation.org