Where Did My Loan Go?
Download
Report
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]