1 / 35

The Meteor Story

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 real-time inquiry of financial aid information One stop, online web service

ryann
Download Presentation

The Meteor Story

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related