A Discussion on Project Meteor and Enterprise Authentication and Authorization (EA2)

1. A Discussion on Project Meteor and Enterprise Authentication and Authorization (EA2) Tim Cameron, Project Meteor Charlie Leonhardt, Georgetown University

2. The Meteor Software The Meteor Network The Meteor Federation The Meteor Project Components

3. Pre-Meteor Environment Lenders, Guarantors, Servicers, Schools and others all offer independent web services Access requires multiple logins FFELP Providers Solution Spring 2000: In response to Federal Modernization Blueprint, NCHELP members move to create an information network to provide aggregated financial aid information. In the beginning….

4. Foundation Principles Open Source Open Collaboration Freely Available Controlled Participation Network Policy and Technology Decisions In the beginning….

5. Access real-time, student-specific financial aid information from multiple sources with an intuitive user interface and navigation Currentlyprovides information on FFELP and alternative loans (capability exists to include Direct Loans & Perkins Loans) Meteor Features

6. 14 Points of access to the Network 20 Data providers Several customized implementations Leading the way for transitive trust in higher education financing Meteor Today

7. Participant Types & Meteor Process Flow

8. Organizations that implement the Meteor software Access Providers (AP) Authentication Agents (AA) Data Providers (DP) Index Providers (IP) Meteor Participants

9. The Meteor Process Authentication (by AP or AA) Access Provider Data Providers Users One Student/Borrower or Financial Aid Professional orAccess Provider RepresentativeorLender Two Index Provider Three

10. Meteor Access Providers

11. Meteor Real Time Data Providers

12. 100% (over 25 million) of FFELP guarantee volume 100% (over 6.5 million) of Direct Loan Program accounts Over 19.2 million FFELP servicer accounts Over 2.9 million Perkins/Private/Alternative Loan servicer accounts The NSC as the Meteor Index Provider

13. Meteor Authentication Objectives & Process

14. 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. Meteor’s Authentication Objectives

15. Assure data owners that only appropriately authenticated end users have access to data. Ensure compliance to participant organizations internal security and privacy guidelines. Meteor’s Authentication Objectives

16. Each Access Provider uses their existing authentication model (single sign-on) Meteor levels of assurance are assigned at registration Meteor Level 3 complies with the NIST Level 2 The Meteor Authentication Model

17. 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 The Meteor Registry

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

19. 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 Meteor’s Authentication Requirements

20. 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 The Meteor Authentication Process

21. Role of end user Social Security Number Authentication Process ID Level of Assurance Date/Time Stamp Information Opaque ID Organization ID Organization Type SAML Assertion Attributes

22. Campus Based Authentication

23. Schools that have entered into an electronic services agreement with the NSC will act as Authentication Agents. NSC will review the school’s authentication policies & procedures Students campus issued credentials will be utilized to access Meteor and other NSC services National Student Clearinghouse School Based Authentication

24. Meteor v3.3 & Software Customization

25. New security features Usability and other navigation improvements Restores NSC LoanLocator services for borrowers Highlights of Version 3.3

27. Meteor Customization

28. Style sheet changes Integration of data into other online services Meteor Customization

29. Meteor network data is presented in NELA branded style sheets

30. Integration of real-time data Advice on borrowing conservatively and maintaining debt Debt/salary wizard Optional budget calculator School customization options Mapping Your Future’s Online Student Loan Counseling

31. Mapping Your Future’s Custom View

32. Using the XML data provided in a Meteor inquiry response, USA Funds populates their exit counseling loan screens with real-time data from the Meteor Network USA Funds Exit Counseling

34. How Could You Use Meteor Data? Integration into Debt Management Solutions Integration into CSR/Call Center Solutions What’s the Catch? Need prior approval from M.A.T. Need to implement Meteor Access Provider Other Customization Options

35. Will serve as a debt management tool Borrowing history presented BEFORE a new award is accepted Ensures that borrower is aware of the potential impact of increasing his aggregate loan(s) amount Total current outstanding New total outstanding with the addition of the new loan Repayment scenarios based on aggregates Online Award Letter Pilot

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

37. 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. EA2 Task Force: History

38. 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: History

39. 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: Defined

40. 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: Membership

41. 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: Motivation

42. 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: Federations

43. 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: Shibboleth

44. 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: Key Problems

45. 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: Towards a Solution

46. 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) 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: Towards a Solution

47. 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 EA2 Task Force: Future

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