The Meteor Story

1. Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor

2. The Meteor Story

3. What is Meteor? • Web-based universal access channel for real-time 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

4. The Meteor Project Components • The Meteor Software • The Meteor Network • The Meteor Federation

5. 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!

6. 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

7. 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

8. Meteor Today • 14 Points of access to the Network • 20 Data providers • Industry leader in standards • Respected Federated model of authentication

9. 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

10. 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

11. The Meteor Process Federated AuthenticationProcess Access Provider Data Providers Users One Student/Borrower or Financial Aid Professional orAccess Provider RepresentativeorLender Two Index Provider Three

12. Meteor Authentication Objectives & Process

13. 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 Gramm-Leach-Bliley Act (GLBA), federal guidelines, and applicable state privacy laws.

14. 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.

15. The Meteor Authentication Model • Each Access Provider uses their existing authentication model (single sign-on) • Meteor levels of assurance are assigned at registration • Level 0 (Unique ID) • Level 1 (Unique ID & 1 piece of validated public data) • Level 2 (Unique ID & 2 pieces of validated public data) • Level 3 (Unique/User ID & shared secret) • Meteor Level 3 complies with the NIST Level 2

16. 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

17. 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.

18. 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

19. 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

20. SAML Assertion Attributes • Role of end user • Social Security Number • Authentication Process ID • Level of Assurance • Opaque ID • Organization ID and Type (Fall 2007)

21. 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

22. For More Information…. • www.MeteorNetwork.org • Audio presentation • Interactive demonstration version of the software • Link to the Meteor project site

23. 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

24. 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 membership-based 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.

25. 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.

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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) `

33. 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

34. 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

35. Contact Information • Tim CameronMeteor Project Manager(954) 565-7229meteor@nchelp.org • Charlie Leonhardt Principal Technologist, Georgetown (202) 687-4011 leonhardt@georgetown.edu