e-Authentication in Higher Education The Project

1. e-Authentication in Higher Education TheProject Presenters: Tim Cameron National Council of Higher Education Loan Programs Tim Bornholtz The Bornholtz Group

2. The Meteor Story

3. What is Meteor? • Web-based network for aggregated real-time inquiry of financial aid information • One stop, online web service • Collaborative effort of the FFELP community • Freely available software and access to the network • Customization options are available

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

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

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

7. Meteor Today • 14 Points of access to the Network • 20 Data providers • School Authentication Agents • Several custom implementations

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

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

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

11. Meteor Authentication Objectives & Process

12. Meteor’s Authentication Objectives • Provide a flexible, easy to implement authentication system. • Ensure compliance with the Gramm-Leach-Bliley Act (GLBA), federal guidelines, and applicable state privacy laws. • Assure data owners that only appropriately authenticated end users have access to data. • Ensure compliance to participant organizations internal security and privacy guidelines.

13. The Meteor Authentication Model • 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

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

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

16. Meteor Technical Architecture

17. Meteor Technical Architecture • Apache SOAP • SAML 1.0 – custom implementation for Meteor • Apache XML Security • Centralized LDAP server with: • Valid participant status • X.509 public key • Contact info • Valid authentication methods

18. SAML Assertion Attributes • Role of end user • Social Security Number • Authentication Process ID • Level of Assurance • Opaque ID • Organization ID and Type

19. Meteor Security - Authentication • Each Access Provider authenticates the users at their local site. • Local security policy is reviewed by Meteor security team • Each provider (Access, Index, Data) is authenticated with X.509 certificates stored in a secure centralized server

20. Meteor Security • Access Control • Coarse grained role-based access control • FAA can view any SSN • Borrower can only see their SSN • CSR can only see SSNs where they are a party • Data confidentiality • All production requests are encrypted with SSL/TLS • Data not stored at Access Provider • Legal agreements in place to determine who can access the network

21. Meteor Security - Nonrepudiation • SAML assertion has: • Issue Instant • Not Before time • Not On Or After time – Default range is 4 hours • Digitally signed with creator’s X.509 cert • Each request has: • Timestamp for issue instant • Default validity is 15 seconds • Digitally signed with Access Provider’s X.509 cert

22. Meteor Logging and Monitoring • Each provider keeps logs for a minimum of one year • Each SAML assertion has an opaque ID • Similar to a userid • Can be used to trace a request through every step of the process • Help Desk monitors network for unusual traffic

23. For More Information…. Interactive Web Site Launched www.MeteorNetwork.org Audio presentation Interactive demonstration version of the software Link to the Meteor project site Project Documentationwww.NCHELP.org/Meteor.htm Implementation Information Current Provider List User Guide and other documentation

24. Contact Information Tim CameronNCHELPmeteor@nchelp.org Tim BornholtzThe Bornholtz Grouptim@bornholtz.com