Title: eAuthentication in Higher Education The Project
1e-Authentication in Higher Education
TheProject
- Presenters
- Tim Cameron
- National Council of Higher Education Loan
Programs - Tim Bornholtz
- The Bornholtz Group
2The Meteor Story
3What 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
4In 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!
5In 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
6In 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
7Meteor Today
- 14 Points of access to the Network
- 20 Data providers
- School Authentication Agents
- Several custom implementations
8Meteor Participant Types
- Organizations that implement the Meteor software
- Access Providers (AP)
- Authentication Agents (AA)
- Data Providers (DP)
- Index Providers (IP)
9The Meteor Process
Access Provider
Federated AuthenticationProcess
Data Providers
Users
One
Student/Borrower or Financial Aid Professional
orAccess Provider RepresentativeorLender
Two
Index Provider
Three
10The 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
11Meteor Authentication Objectives Process
12Meteors 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.
13The 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
14Meteors 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.
15Meteors 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
16Meteor Technical Architecture
17Meteor 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
18SAML Assertion Attributes
- Role of end user
- Social Security Number
- Authentication Process ID
- Level of Assurance
- Opaque ID
- Organization ID and Type
19Meteor 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
20Meteor 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
21Meteor 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
22Meteor 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
23For 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
24Contact Information
- Tim CameronNCHELPmeteor_at_nchelp.org
- Tim BornholtzThe Bornholtz Grouptim_at_bornholtz.co
m