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 declaring permissions (by the endpoint) and implementing permissions.
Enterprise
We don't have a great user-roles story.
Right now, we assume that having API access implies admin access.
Using a Django group: enterprise_enrollment_api_access
- 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
- Association with an enterprise (enterprise-customer-user)
- Role within the enterprise
- User
- Admin
- Financial Admin (future?)
- Theoretically, a user can be affiliated with multiple enterprises.
Masters requirements
- 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
- Question: If we have the following organization types: enterprise-org and content-provider-org, where does masters fit in?