Current Design Patterns

API scopes (OEP-4) & Filters (OAuth decisions)

To limit the access of the calling OAuth client application
The OAuth2 application may be calling
- on behalf of itself (server-to-server call via Client Credentials) or
- on behalf of a user (via Auth Code, Implicit, or Password)
Intended to be separate from enforcing user-level permissions, since this is designed for application access not user access.
However, we do see the Insights application adding user-level roles (staff) to the OAuth token. It doesn't scale too well though, as soon as they added all course-staff roles to the token.

Separation of concerns between querying permissions (by the endpoint) and implementing permission checks.

Enterprise

Data API gets the JWT, calls the LMS to get the user details, looks up enterprise affiliation via an LMS API - can be chatty (though there is a cache).
Keeps track of being "associated" with an enterprise.

Enterprise Roles

Flipped application process: managed by masters organization
If based on enterprise, there may be a concept of having a "primary" enterprise.
APIs
- Enrollments
- Cohort
- Grades
- Completion
- Student Records

Nimisha Asthagiri (Deactivated) write current design thoughts on capturing system-wide roles in JWT tokens, and proposal for including enterprise association in JWTs.
Douglas Hall (Deactivated), George Babey (Deactivated), Brittney Exline (Deactivated), Nimisha Asthagiri (Deactivated) Dive deeper into enterprise design (perhaps after/during step 1).
Scott Dunn (Deactivated) share Masters use cases.
Scott Dunn (Deactivated) answer the question: if we have the following organization types: enterprise-org and content-provider-org, where does masters fit in?