1 / 24

Authentication

Authentication. Presenter Meteor Advisory Team Member. Version 1.1. Glossary. FAP - Financial Aid Professional. Individuals, working for schools, who are seeking information on a student's loan in order to advise and assist students with financial aid.

rsouthern
Download Presentation

Authentication

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication Presenter Meteor Advisory Team Member Version 1.1

  2. Glossary • FAP - Financial Aid Professional. Individuals, working for schools, who are seeking information on a student's loan in order to advise and assist students with financial aid. • MAT - Representatives from the Meteor sponsors, NCHELP, and partnering organizations responsible for the design and implementation of the Meteor project.

  3. Assumptions: • All Index, Access & Data Providers are assigned a Unique ID by the MAT (Meteor Advisory Team). • Within Meteor, students/borrowers are identified by an element called ”Student/Borrower ID" (which is their SSN). • Within Meteor, FAPs are identified by a pair of elements: • The OPE ID (identifies their institution) • A local user identifier, which is unique within their institution (assigned by the AP).

  4. Assumptions: (Cont.) • This presentation will refer to various kinds of Assertions. These are SAML Assertions (see http://www.oasis-open.org/committees/security/). • Currently, there are two possible Roles: • Borrower (authorized to see only their own data) • FAP (authorized to see data on all students) • An Authentication Assertion identifies the person submitting a QUERY. This may be different from the subject of the query.

  5. Being Recognized as an Index, Access & Data Provider • An interested party submits a Meteor Provider Registration Request to the Meteor Advisory Team (MAT). • MAT manually reviews the request. As part of this review the MAT reviews the Access Provider authentication process for each role/group and assigns an assurance level to each.

  6. Being Recognized as an Index, Access & Data Provider (cont.) • The MAT assigns a Unique ID to the party (a logical name, distinct from the names used for signing). The new party generates a key pair, and provides a Digital Certificate to the MAT. • The MAT adds the new party to its Registry.

  7. User Requesting Information • The user connects to a specific Access Provider (AP) and authenticates. • The AP determines the role for this user (FAP or Borrower) based on local authentication procedures. • The AP software determines the default assurance level that corresponds with the role of the user.

  8. User Requesting Information (cont.) • The AP software builds an Authentication Assertion, which includes: • The AP’s Unique ID • Authentication Process ID • Session ID • The role of the user • A local user identifier • If the role is FAP, then this is the OPE ID and a unique local user ID associated with the user • If the role is borrower, then this is the borrower's SSN • The assurance level

  9. User Requesting Information (cont.) • The AP software signs the Authentication Assertion. • The AP software looks in the Registry (cached local copy), and finds all the Index Providers (IP). It builds an IP Query Request for each IP, asking for the Data Providers (DP) with loan information relevant to this student/borrower. This IP Query Request includes: • The Unique ID of the AP • The Authentication Assertion (the user making the request) • The subject of the query

  10. User Requesting Information (cont.) • The AP software signs the request, and sends it to each of the Index Providers. • An IP validates the signature on the request. The IP then verifies that the requestor is a trusted speaker (authorized to submit these requests) by looking at the AP's entry in the Registry. The IP then builds an IP Response Message, signs it, and returns it to the AP.

  11. User Requesting Information (cont.) • The AP software validates the signature on the response, and verifies that the responder is a trusted speaker. The AP software then builds a consolidated list of Data Providers thought to be holding information about this student/borrower.

  12. User Requesting Information (cont.) • The AP software validates each DP against the Meteor Registry to determine that they are an authorized Meteor Data Provider and that the assurance level of the user is at least at the level required by the DP. If the current assurance level is insufficient, then the AP software will present a list and ask the borrower if they have a relationship with any DP listed with a higher level of assurance.

  13. User Requesting Information (cont.) • The user may then choose to perform further authentication via a link presented or to view an incomplete set of loan data provided only by those DPs who accept the current level of assurance..

  14. User Requesting Information (cont.) • The AP builds a DP Query Request for each DP. This request includes: • AP's Unique ID • The current Authentication Assertion • The subject of the query (Student/Borrower SSN) • Request ID (Date, Time, and a sequentially generated sequence number)

  15. User Requesting Information (cont.) • The request is signed by the AP software. The requests are sent to each valid Data Provider.

  16. User Requesting Information (cont.) • The DP software validates the Access Provider. • Validate the AP signature on the Query. • DP software verifies that the signer of the Query (AP) is a trusted speaker (via the Meteor Registry).

  17. User Requesting Information (cont.) • The DP software validates the Authentication Assertion. • The DP software validates the signature on the Authentication Assertion. • The DP software verifies that the signer is a trusted speaker (via the Meteor Registry).

  18. User Requesting Information (cont.) • DP assesses the assurance level. • If it is insufficient, then the DP software returns an error to the AP ("Access Denied because of Authn level"). • Upon receiving this response, the AP software will recognize that a Registry synchronization problem exists and will check for Central Registration updates. • Alternatively, if the assurance level is insufficient, the DP software can choose to ignore the query and not respond.

  19. User Requesting Information (cont.) • The DP software will perform standard error checking • (eg replay detection -- The combination of Access Provider ID, QuerySubject, Date, and sequence number are compared to the request log to verify this is not a duplicate request.)

  20. User Requesting Information (cont.) • The DP software logs the Access Provider request.

  21. User Requesting Information (cont.) • The DP software builds a response. • DP software indicates no data exist. • DP software chooses not to respond. • DP software denies data access. • DP software populates the data. • The DP software signs the response,and returns it to the AP. • The AP software validates the signature. • The AP software displays the results for the user.

  22. Feedback on Authentication E-mail addresses of speakers

  23. Meteor Ongoing Status For current status and updates: go to www.NCHELP.org and click on the Meteor Project logo.

  24. Questions & Feedback

More Related