slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor PowerPoint Presentation
Download Presentation
Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor

Loading in 2 Seconds...

play fullscreen
1 / 35

Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor - PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on

Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor. The Meteor Story. What is Meteor?. Web-based universal access channel for real-time inquiry of financial aid information One stop, online web service

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Extending Enterprise Authentication and Authorization in Higher Education: Building on the Success of Project Meteor

what is meteor
What is Meteor?
  • Web-based universal access channel for real-time inquiry of financial aid information
  • One stop, online web service
  • Aggregated information to assist Financial Aid Professionals, students and borrowers with debt counseling and the aid process in general
  • Collaborative effort of the FFELP community
  • Freely available software and access to the network
the meteor project components
The Meteor Project Components
  • The Meteor Software
  • The Meteor Network
  • The Meteor Federation
in the beginning
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 beginning6
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 beginning7
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
Meteor Today
  • 14 Points of access to the Network
  • 20 Data providers
  • Industry leader in standards
  • Respected Federated model of authentication
the meteor network
The Meteor Network
  • Meteor Access and Authentication
    • Federated Model: Transitive Trust
    • Multiple points of access with multiple authentication processes
  • User Roles
    • School
    • Student/Borrower
    • Customer Service Representatives
    • Lenders
the meteor network10
The Meteor Network
  • Index Provider
    • Provides the location of entities that have data for the account being accessed
    • Current provider:
      • The National Student Clearinghouse
  • Data Providers
    • Guarantors
    • Servicers
    • Lenders
    • Others
the meteor process
The Meteor Process

Federated AuthenticationProcess

Access Provider

Data Providers

Users

One

Student/Borrower or

Financial Aid Professional orAccess Provider RepresentativeorLender

Two

Index Provider

Three

meteor s authentication objectives
Meteor’s Authentication Objectives
  • Provide a flexible, easy to implement authentication system that meets the needs of the provider organizations and their customers.
  • Ensure compliance with the Gramm-Leach-Bliley Act (GLBA), federal guidelines, and applicable state privacy laws.
meteor s authentication objectives14
Meteor’s Authentication Objectives
  • 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
The Meteor Authentication Model
  • Each Access Provider uses their existing authentication model (single sign-on)
  • Meteor levels of assurance are assigned at registration
    • Level 0 (Unique ID)
    • Level 1 (Unique ID & 1 piece of validated public data)
    • Level 2 (Unique ID & 2 pieces of validated public data)
    • Level 3 (Unique/User ID & shared secret)
  • Meteor Level 3 complies with the NIST Level 2
the meteor registry
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 s authentication requirements
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 requirements18
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
the meteor authentication process
The Meteor Authentication Process
  • End user authenticates at access provider site or through a Meteor approved third party Authentication Agent
  • Access provider creates authentication assertion (SAML)
  • Access provider signs authentication assertion with digital certificate
saml assertion attributes
SAML Assertion Attributes
  • Role of end user
  • Social Security Number
  • Authentication Process ID
  • Level of Assurance
  • Opaque ID
  • Organization ID and Type (Fall 2007)
industry collaboration
Industry Collaboration
  • Postsecondary Electronic Standards Council (PESC)
    • Student Aid Inquiry Standard
      • Collaboration with ELM and FSA
    • Electronic Authentication & Authorization Task Force
      • GOAL: Work on building interoperability among Federations in the higher education community
      • Members include:
        • Educause
        • InCommon
        • Liberty Alliance
        • U.S. Department of Education
        • The Meteor Project
for more information
For More Information….
  • www.MeteorNetwork.org
    • Audio presentation
    • Interactive demonstration version of the software
    • Link to the Meteor project site
upcoming user group meetings
Upcoming User Group Meetings
  • October 30, 2007
    • FSA Conference – New Orleans
      • 5:00 pm, Napoleon B1/C1 room
  • November 26, 2007
    • FSA Conference – San Diego
      • 5:00pm, Edward room

RSVP by sending and email to meteor@nchelp.org

ea2 task force history
EA2 Task Force: History
  • Electronic Authorization Partnership (EAP) was a multi-industry partnership working on the vital task of enabling interoperability among public and private electronic authentication systems.
  • In December 2002, Johns Hopkins University convened a symposium of experts from both the public and private sectors to examine the best approach for governing identity management. The symposium issued a paper calling for creation of a "Stakeholder Council" to develop operating rules on identity management.
  • In 2005, EAP was formally established as a 501(c)(3) non-profit membership-based association including: PESC, American Association of Motor Vehicle Administrators (AAMVA); BITS Financial Services Roundtable; the U.S. General Services Administration (GSA); Healthcare Information and Management Systems Society (HIMSS); Microsoft Corporation; Mortgage Bankers Association (MBA); the National Automated Clearinghouse Association (NACHA); the National Association of State Auditors, Comptrollers, and Treasurers (NASACT); and Wells Fargo, among many others.
ea2 task force history25
EA2 Task Force: History
  • In 2007, Electronic Authorization Partnership technical activities and intellectual property were merged into the Liberty Alliance; the organization while still in existence will cease activities in the near future .
  • EA2 was formed to continue “functional” instigation within the higher education community and service providers to higher education, to increase inter-organizational collaboration, to see single sign on become a reality in higher education, and to further the success of the InCommon and Meteor federations.
ea2 task force defined
EA2 Task Force: Defined
  • Dramatically increase the number of users who have access to federated authentication and authorization in the United States and beyond (particularly in higher education)
  • Dramatically increase the number of applications / service providers that are EA2 capable (with a special interest in the U.S. Department of Education services)
  • Assist in the resolution of policy issues whenever possible
  • Assist in the resolution of technology and implementation issues
  • Enhance awareness of EA2 initiatives
  • Assist current efforts of the Internet2 community wherever possible
ea2 task force membership
EA2 Task Force: Membership
  • Rob Abel, IMS Global Learning Consortium
  • Ellen Blackmun, NASFAA
  • Tim Cameron, NCHELP/Project Meteor
  • Charlie Coleman, FSA, U.S. Department of Education
  • Larry Fruth, SIFA
  • Ken Klingenstein, Internet2/InCommon Federation
  • Nancy Krogh, AACRAO
  • Hans L’Orange, State Higher Education Executive Officers (SHEEO)
  • Charlie Leonhardt, Georgetown
  • Adele Marsh, AES/PESC
  • Vacant, GSA/Federal E-Authentication Initiative
  • Brett McDowell, Liberty Alliance / E-Authentication Partnership
  • David Temoshok, GSA/E-Authentication Partnership
  • Steve Worona, EDUCAUSE
ea2 task force motivation
EA2 Task Force: Motivation
  • Our customers (students, parents, faculty, staff, alumni, donors, visitors) want:
    • Everything
    • Anywhere
    • Anytime (i.e. “now”)
  • They would like it delivered:
    • Inexpensively or “free”
    • Conveniently and painlessly (“don’t make me login 15 times to 15 different services)
    • With guarantees of information security and privacy
ea2 task force federations
EA2 Task Force: Federations
  • There is an excellent case for a federated approach for authentication (“I am who I say I am”) and authorization (“I can do this based on my role / location / whatever”)
  • Federated approach implies trust and agreement among “service providers” (hosted applications) sites and “consumer” (provider of credentials) sites
  • SAML and Shibboleth (Internet2 middleware technology) allow service providers to refer to consumer sites for authentication
  • Once authenticated, a second referral is made to a consumer site to obtain attribute data to be used in making application authorization decisions
  • Excellent example: worldwide ATM network
ea2 task force shibboleth
EA2 Task Force: Shibboleth
  • Internet2 middleware initiative developed by a number of Universities and funded by NSF
  • InCommon Federation formed – now has 50 higher education and 20 “service provider” members; info at http://incommonfederation.org
  • Attempts to solve inter-institutional trust / authentication / authorization issues; has wide applicability among H.E. institutions and organizations that serve higher ed
  • Standards-based, open source implementation
  • Policy based, trusted federations
  • Common goal: use non-native, non-centralized, trusted “third party” authentication/authorization
ea2 task force key problems
EA2 Task Force: Key Problems
  • Trust has not yet been established between InCommon

and other federations (e.g. Federal E-Auth, Meteor, the UK and Canadian Federations)

  • Policy and Procedural Issues (particularly around identity management (IdM) and “levels of assurance”) are unresolved
  • Variability in the deployment of IdM systems
  • Easy-to-use toolkits to connect identity management systems to federated environments are generally “NA”
  • Challenges in the deployment of open source environments for EA2
  • Variability in implementation of Credential Management Policies and Procedures
ea2 task force towards a solution
EA2 Task Force: Towards a Solution
  • Shibboleth 2.0 (including SAML 2.0) released last month
  • NIST published revisions to Credential Assessment Framework and associated LOAs.
  • FSA/US Dept of Education announced a willingness to EA2 enable their applications (limited in scope) in March 2007
  • Higher Education needs to work with the vendor and open source communities to embed EA2 services in Applications (Google, Apple, VLEs, Publishers, Community Source Student Services, many business applications)

`

ea2 task force towards a solution33
EA2 Task Force: Towards a Solution
  • U.S. Dept. of Education / FSA will E-Auth enable campus-based programs (FWS, Perkins) to allow students to access data (if their schools are Federal E-Auth Compliant) beginning in March 2008
  • Liberty Alliance working hard on an Identity Assurance Framework and the design of a credential assessment accreditation process
  • Liberty will have a document for public comment available in November
  • There is a big push to get InCommon LOAs “in synch” with Federal E-Auth LOAs to establish inter-federation trust
ea2 task force future
EA2 Task Force: Future
  • Monthly Conference Calls
  • Policy Development Work
  • Pilot Projects
  • Convincing Government Agencies, Commercial application providers, Open Source Initiatives, and K-20 computing environments to embed EA2 frameworks within as many applications as possible
  • Work on deploying tools and methods to expand EA2 initiatives
  • Increasing awareness of the importance of EA2 frameworks to achieve the level of customer service and security that we all envision
slide35

Contact Information

  • Tim CameronMeteor Project Manager(954) 565-7229meteor@nchelp.org
  • Charlie Leonhardt

Principal Technologist, Georgetown

(202) 687-4011

leonhardt@georgetown.edu