Extending Enterprise
Authentication and Authorization
in Higher Education: Building on
the Success of Project Meteor
The Meteor Story
What is Meteor?
• Web-based universal access channel for realtime inquiry of financial aid information
• One stop, online web service
• Aggregated information to assist Financial Aid
Professionals, students and borrowers with debt
counseling and the aid process in general
• Collaborative effort of the FFELP community
• Freely available software and access to the
network
The Meteor Project Components
• The Meteor Software
• The Meteor Network
• The Meteor Federation
In the beginning….
• Pre-Meteor Environment (1980’s & 1990’s)
– Lenders, Guarantors, Servicers, Schools and
others all offered independent web services
– Required multiple logins
– Low level of security:
• Many required only SSN and DOB to access
financial aid award data!
In the beginning….
• Department of Education Modernization
Plans
– Performance Based Organization approved
with Higher Education Amendments in 1998
• Modernization Blueprint
–
–
–
–
Released September 30, 1999
Second Edition - 2000
Third Edition – 2001
Fourth Edition – 2002
In the beginning….
• FFELP Providers Solution
– Spring 2000: CEO meeting sponsored by
NCHELP
– Critical decisions:
• Create an information network to provide
aggregated financial aid information.
– Foundation Principles
• Open Source
• Open Collaboration
• Freely Available
• Controlled Participation Network
Meteor Today
•
•
•
•
14 Points of access to the Network
20 Data providers
Industry leader in standards
Respected Federated model of
authentication
The Meteor Network
• Meteor Access and Authentication
– Federated Model: Transitive Trust
– Multiple points of access with multiple
authentication processes
• User Roles
– School
– Student/Borrower
– Customer Service Representatives
– Lenders
The Meteor Network
• Index Provider
– Provides the location of entities that have
data for the account being accessed
– Current provider:
• The National Student Clearinghouse
• Data Providers
– Guarantors
– Servicers
– Lenders
– Others
The Meteor Process
Users
Federated
Authentication
Process
Access
Provider
One
Student/Borrower
or
Financial Aid
Professional
or
Access Provider
Representative
or
Lender
Data Providers
Two
Index
Provider
Three
Meteor Authentication
Objectives & Process
Meteor’s Authentication Objectives
• Provide a flexible, easy to implement
authentication system that meets the
needs of the provider organizations and
their customers.
• Ensure compliance with the GrammLeach-Bliley Act (GLBA), federal
guidelines, and applicable state privacy
laws.
Meteor’s Authentication Objectives
• Assure data owners that only appropriately
authenticated end users have access to data.
• Ensure compliance to participant organizations
internal security and privacy guidelines.
The Meteor Authentication Model
• Each Access Provider uses their existing
authentication model (single sign-on)
• Meteor levels of assurance are assigned at
registration
–
–
–
–
Level
Level
Level
Level
0
1
2
3
(Unique ID)
(Unique ID & 1 piece of validated public data)
(Unique ID & 2 pieces of validated public data)
(Unique/User ID & shared secret)
• Meteor Level 3 complies with the NIST Level 2
The Meteor Registry
• Each participant is required to register, sign a participation
agreement, and submit policies and procedures surrounding
their authentication process.
• The Meteor Team Leads review the policies and procedures
and assign a Level of Assurance
• Meteor uses a centralized LDAP server to contain:
• Public keys of all participants
• Network status information (active, pending, suspended)
• Contact Information
Meteor’s Authentication Requirements
• User is required to provide an ID and a
shared secret.
• Assignment and delivery of shared secret
must be secure.
• Assignment of shared secret is based on
validated information.
• Reasonable assurances that the storage of
the IDs and shared secrets are secure.
Meteor’s Authentication Requirements
• Access provider must ensure appropriate
authentication for each end user and provide
traceability back to that user
• Access provider must provide authentication policy
to central authority
• Access provider must provide central authority with
30 day advance notice of changes to authentication
policy
• Access provider must agree to appropriate use of
data
The Meteor Authentication Process
• End user authenticates at access provider
site or through a Meteor approved third
party Authentication Agent
• Access provider creates authentication
assertion (SAML)
• Access provider signs authentication
assertion with digital certificate
SAML Assertion Attributes
• Role of end user
• Social Security Number
• Authentication Process ID
• Level of Assurance
• Opaque ID
• Organization ID and Type (Fall 2007)
Industry Collaboration
• Postsecondary Electronic Standards Council
(PESC)
– Student Aid Inquiry Standard
• Collaboration with ELM and FSA
– Electronic Authentication & Authorization Task Force
• GOAL: Work on building interoperability among Federations
in the higher education community
• Members include:
–
–
–
–
–
Educause
InCommon
Liberty Alliance
U.S. Department of Education
The Meteor Project
For More Information….
• www.MeteorNetwork.org
– Audio presentation
– Interactive demonstration version of the
software
– Link to the Meteor project site
Upcoming User Group Meetings
• October 30, 2007
– FSA Conference – New Orleans
• 5:00 pm, Napoleon B1/C1 room
• November 26, 2007
– FSA Conference – San Diego
• 5:00pm, Edward room
RSVP by sending and email to
meteor@nchelp.org
EA2 Task Force: History
•
•
•
Electronic Authorization Partnership (EAP) was a multi-industry partnership
working on the vital task of enabling interoperability among public and
private electronic authentication systems.
In December 2002, Johns Hopkins University convened a symposium of
experts from both the public and private sectors to examine the best
approach for governing identity management. The symposium issued a paper
calling for creation of a "Stakeholder Council" to develop operating rules on
identity management.
In 2005, EAP was formally established as a 501(c)(3) non-profit membershipbased association including: PESC, American Association of Motor Vehicle
Administrators (AAMVA); BITS Financial Services Roundtable; the U.S.
General Services Administration (GSA); Healthcare Information and
Management Systems Society (HIMSS); Microsoft Corporation; Mortgage
Bankers Association (MBA); the National Automated Clearinghouse
Association (NACHA); the National Association of State Auditors,
Comptrollers, and Treasurers (NASACT); and Wells Fargo, among many
others.
EA2 Task Force: History
• In 2007, Electronic Authorization Partnership technical activities and
intellectual property were merged into the Liberty Alliance; the
organization while still in existence will cease activities in the near
future .
• EA2 was formed to continue “functional” instigation within the higher
education community and service providers to higher education, to
increase inter-organizational collaboration, to see single sign on
become a reality in higher education, and to further the success of
the InCommon and Meteor federations.
EA2 Task Force: Defined
• Dramatically increase the number of users who have access to
federated authentication and authorization in the United States and
beyond (particularly in higher education)
• Dramatically increase the number of applications / service providers
that are EA2 capable (with a special interest in the U.S. Department
of Education services)
• Assist in the resolution of policy issues whenever possible
• Assist in the resolution of technology and implementation issues
• Enhance awareness of EA2 initiatives
• Assist current efforts of the Internet2 community wherever possible
EA2 Task Force: Membership
•
Rob Abel, IMS Global Learning Consortium
•
Ellen Blackmun, NASFAA
•
Tim Cameron, NCHELP/Project Meteor
•
Charlie Coleman, FSA, U.S. Department of Education
•
Larry Fruth, SIFA
•
Ken Klingenstein, Internet2/InCommon Federation
•
Nancy Krogh, AACRAO
•
Hans L’Orange, State Higher Education Executive Officers (SHEEO)
•
Charlie Leonhardt, Georgetown
•
Adele Marsh, AES/PESC
•
Vacant, GSA/Federal E-Authentication Initiative
•
Brett McDowell, Liberty Alliance / E-Authentication Partnership
•
David Temoshok, GSA/E-Authentication Partnership
•
Steve Worona, EDUCAUSE
EA2 Task Force: Motivation
• Our customers (students, parents, faculty, staff,
alumni, donors, visitors) want:
– Everything
– Anywhere
– Anytime (i.e. “now”)
• They would like it delivered:
– Inexpensively or “free”
– Conveniently and painlessly (“don’t make me login
15 times to 15 different services)
– With guarantees of information security and privacy
EA2 Task Force: Federations
• There is an excellent case for a federated approach for
authentication (“I am who I say I am”) and authorization (“I can do
this based on my role / location / whatever”)
• Federated approach implies trust and agreement among “service
providers” (hosted applications) sites and “consumer” (provider of
credentials) sites
• SAML and Shibboleth (Internet2 middleware technology) allow
service providers to refer to consumer sites for authentication
• Once authenticated, a second referral is made to a consumer site
to obtain attribute data to be used in making application
authorization decisions
• Excellent example: worldwide ATM network
EA2 Task Force: Shibboleth
• Internet2 middleware initiative developed by a number of
Universities and funded by NSF
• InCommon Federation formed – now has 50 higher education and
20 “service provider” members; info at
http://incommonfederation.org
• Attempts to solve inter-institutional trust / authentication /
authorization issues; has wide applicability among H.E. institutions
and organizations that serve higher ed
• Standards-based, open source implementation
• Policy based, trusted federations
• Common goal: use non-native, non-centralized, trusted “third party”
authentication/authorization
EA2 Task Force: Key Problems
• Trust has not yet been established between InCommon
and other federations (e.g. Federal E-Auth, Meteor, the UK and
Canadian Federations)
• Policy and Procedural Issues (particularly around identity
management (IdM) and “levels of assurance”) are unresolved
• Variability in the deployment of IdM systems
• Easy-to-use toolkits to connect identity management systems to
federated environments are generally “NA”
• Challenges in the deployment of open source environments for EA2
• Variability in implementation of Credential Management Policies and
Procedures
EA2 Task Force: Towards a
Solution
• Shibboleth 2.0 (including SAML 2.0) released last
month
• NIST published revisions to Credential
Assessment Framework and associated LOAs.
• FSA/US Dept of Education announced a
willingness to EA2 enable their applications
(limited in scope) in March 2007
• Higher Education needs to work with the vendor
and open source communities to embed EA2
services in Applications (Google, Apple, VLEs,
Publishers, Community Source Student Services,
many business applications)
EA2 Task Force: Towards a
Solution
• U.S. Dept. of Education / FSA will E-Auth enable
campus-based programs (FWS, Perkins) to allow
students to access data (if their schools are
Federal E-Auth Compliant) beginning in March
2008
• Liberty Alliance working hard on an Identity
Assurance Framework and the design of a
credential assessment accreditation process
• Liberty will have a document for public comment
available in November
• There is a big push to get InCommon LOAs “in
synch” with Federal E-Auth LOAs to establish
inter-federation trust
EA2 Task Force: Future
•
•
•
•
Monthly Conference Calls
Policy Development Work
Pilot Projects
Convincing Government Agencies, Commercial
application providers, Open Source Initiatives, and K-20
computing environments to embed EA2 frameworks
within as many applications as possible
• Work on deploying tools and methods to expand EA2
initiatives
• Increasing awareness of the importance of EA2
frameworks to achieve the level of customer service and
security that we all envision
Contact Information
• Tim Cameron
Meteor Project Manager
(954) 565-7229
meteor@nchelp.org
• Charlie Leonhardt
Principal Technologist, Georgetown
(202) 687-4011
leonhardt@georgetown.edu