eAuthentication 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 (1980s 1990s)
• 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
Access Provider
Federated AuthenticationProcess
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
Meteors 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
Meteors 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
Meteors 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 creators X.509 cert
• Each request has
• Timestamp for issue instant
• Default validity is 15 seconds
• Digitally signed with Access Providers 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.or
  g
• 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_at_nchelp.org
• Tim BornholtzThe Bornholtz Grouptim_at_bornholtz.co
  m