Because OAuth2 is the desired authentication process, and it is a well-known and well-supported protocol, completing a full-blown authentication integration is a low-value task for this project.
To support authorization, there is a token endpoint with two hard-coded sets of client credentials. These will return a JSON Web Token (JWT) that should be used on all HTTP requests when authorization is enabled. The JWT is signed with a signing key, which must be provided via the SIGNING_KEY environment variable.
Key
Secret
meadowlark_key_2
meadowlark_secret_2
meadowlark_key_1
meadowlark_secret_1
Authorization
The authorization requirement can be turned off with an environment variable, ACCESS_TOKEN_REQUIRED (true or false). When true, "ownership" based authorization is enforced. This authorization enforces that the client who creates a resource is the only one who can access that resource. For the purpose of this project, this is seen as a minimum viable product showing that a resource-level restriction can be applied on GET, UPDATE, and DELETE requests.
The project does not seek to replicate the complex authorization schemes available in the Ed-Fi ODS/API, including authorization based on vendor's ability to access an education organization. If the project were ever to evolve into a product, then further conversations would need to be had with the community to determine what authorization mechanisms are minimally required.
Infrastructure
Because this is a research and development project, only minimal effort was put into securing the infrastructure. When deployed to Amazon, the team did try to keep access permissions to the minimum necessary to achieve the purpose. There was no attempt to minimize the database access permissions; for example, the Lambda functions can create tables and access all records. This may or may not be a desirable pattern in a real production system.