First Draft - Security Requirements for Campus Student API

Owned by Diana Antova
Last updated: Jun 28, 2018 by Steven Maglio
2 min read
Project TitleCampus Student API
Target releaseCampus Student API
Epic
Document status
DRAFT
Document owner

Diana Antova

Document Sign-Off
Subject Matter Expert(s)Anthony Schmid, Michael Nesbit (Unlicensed), James Kinneavy
Technical Expert(s)Steven Maglio, Adam Sottosanti (Deactivated), Ann Crawford (Unlicensed), Seth Northrop

Background & Business Value

Goals

  • Provide access to student data to the campus community for application development outside of SIS&T in a secure and standardized way.

Background and strategic fit

So far developers on campus have been getting student data by running Gaucho Blue extracts several times a quarter, and importing the data into their systems. Alternatively some of them have gained access to student data thru SIS&T's operational data store, where firewall rules have been put in place to allow external departments to access our ODS server. Still, some people on campus have developed applications, where the student data is fed thru copy/paste methods very infrequently. 

All these cases make our data insecure as it requires that it is saved in these external systems. The information is not timely refreshed, it requires a lot of manual intervention, and it leads to many different interpretations.

SIS&, as the custodian of the Student Information System data, is responsible to provide it to campus partners in a secure and standardized way to meet their business needs. 

The campus API management tool (Apigee) implementation project provides a platform for accomplishing our goals of proving access to the student data in a secure and standard way.

Assumptions

  • Campus developers will want to transition their applications to utilize the new student and curriculum APIs. 
  • Apigee contract will be extended by the CIO office going forward.

Out of Scope

Requirements

ID#TitleUser StoryPriorityNotesStatus
1Authenticate the end-user

As a data provider identify the user accessing my data

Must have
  • Current cases are allowed to see all students

  • Phase 2 will implement user authentication once we have cases for it

To Do
2Authenticate the application

Allow an application to access API(s)



  • Will use API Keys in the initial release.
  • Will change to campus OAuth in the future when ETS recourses become available.

3 Authorize the end-user As a data provider limit the scope of data to which the end-user has access

As an end-user access the data that they are allowed to access


  • Phase 2 will implement user authorization once we have cases for it

4

 Ability to limit data elements returned for an application

 Per application limit the data elements that we allow access toMust have 
  • Will implement in Phase 1
  • Will use basic and extended objects and customer specific objects.
  • In Apigee we will use API products to limit access.

5All API requests should be encrypted Use https for all API calls
  • Phase 1

6 All services should be reasonably secured from unintended access

 As a service provider services should not be accessed from unknown entities on the internet.



  • Use IP whitelisting as a preferred choice, when possible
  • Use shared secret if IP whitelisting is not possible

7 PL4 level data in APIs might require encryption

PL4 - SSN, financial and medical data



  •  Will discuss further needs for encryption if a need comes up for PL4 level APIs.

User interaction, design & Architecture

Examples and References

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcomeDecision Date