We will need to do a code review of the application
We will need to come up with language that says you will use the student credentials securely that they will need to sign
The language will also need to state terms of notifications for potential problems (will this make it an official endorsement which will then create legal liabilities )
Most likely we should use the Standard DS (Data Security) agreement
We will need to do periodic reviews of the application to ensure the application keeps the security standards in place
Our View Point on this Scenario
Student developed apps should be given just as much opportunity as staff developed apps
Their needs to be a security review of any app that is using an API which requires approval before it's approved through the Campus Web API Gateway
Reviews of the application will be with team that developed the application and the API Gateway Team
A previous review with a development team can be used to approved any future applications that they create
Student developed apps will need to sign extra agreements (like Security DS)
Staff developed apps will not need this because the agreement is already part of working on the campus
Farah found that the 100 requests per minute (default quota level) to be too limiting. She also found that the way the quota level is implemented, the system will literally have to wait for the full minute to expire before allowing requests to flow again.
The smallest increment of time we can do in the UI is per minute. The REST API has the same limitation.
What would we think about ...
1000 per minute (60 ms per request)
10000per minute (6 ms per request)
20000 per minute (3 ms per request)
I made some calls with the tracing tool turned on just to see how long a "simple call" takes to return.
