API Authorization: Enterprise and Masters use cases

Owned by Nimisha Asthagiri (Deactivated)
Last updated: Feb 08, 2021

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.

OEP-9

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

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

Next Steps