Transcript Where Did My Loan Go?

e-Authentication in Higher Education
The
Project
Presenters:
Tim Cameron
National Council of Higher Education Loan Programs
Tim Bornholtz
The Bornholtz Group
The Meteor Story
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
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!
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
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
Meteor Today
14 Points of access to the Network
 20 Data providers
 School Authentication Agents
 Several custom implementations

Meteor Participant Types

Organizations that implement the Meteor
software
Access Providers (AP)
 Authentication Agents (AA)
 Data Providers (DP)
 Index Providers (IP)

The Meteor Process
Users
Federated
Authentication
Process
Access
Provider
One
Student/Borrower
or
Financial Aid
Professional
or
Access Provider
Representative
or
Lender
Data Providers
Two
Index
Provider
Three
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
Meteor Authentication
Objectives & Process
Meteor’s Authentication
Objectives




Provide a flexible, easy to implement
authentication system.
Ensure compliance with the Gramm-LeachBliley 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.
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

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.
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
Meteor Technical Architecture
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

SAML Assertion Attributes

Role of end user

Social Security Number

Authentication Process ID

Level of Assurance

Opaque ID

Organization ID and Type
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

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
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
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
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 Documentation
www.NCHELP.org/Meteor.htm
 Implementation Information
 Current Provider List
 User Guide and other
documentation
Contact Information


Tim Cameron
NCHELP
[email protected]
Tim Bornholtz
The Bornholtz Group
[email protected]