Page Comparison

...

We implemented an AuthEvaluator class that can be used to describe static objects that will check our different authorization rules. (If they are precondition checks…sometimes Sometimes we still need to do a verification on models returned from the system, which are more along the lines of postcondition checks (not covered…e.g. “is this object you just loaded is in associated to the study we just verified you have access to.?”)

The AuthEvaluator roles rules can be called in the controllers, then it’s possible much easier to find the authorization rule for a given API endpoint when writing SDK documentation. The evaluator currently has an overly-broad rule that needs to be removed for more specific checks.:

...

ADMIN - all authorization checks should succeed for ADMINS ADMINs. They should be excepted in the AuthEvaluator, then they can be removed from getSession(…) checks.

A SUPERADMIN is an ADMIN in all respects, but who has APIs to switch between studies apps without having to have an account in each app (UserManagementController.signInForSuperAdmin and AuthenticationController.changeApp). Admin and Superadmin SDK clients can just define the APIs, like the cache or app creation APIs, that are only available to those roles, since all the other clients will work and succeed for these users.

This is not fully or consistently implemented, see:

DEVELOPER, RESEARCHER - These divide the APIs into endpoints that manipulate app configuration and endpoints that between calls to configure an app and calls to return information about study participants (include PII). They are app-scoped, and too broad for apps that have multiple studies run by different researchers.

We might choose to allow these roles access to their study-scoped alternates (described below). They would then be supersets of those roles. See:

STUDY COORDINATOR - This is a study-scoped version of a researcher (they can only access studies that they have access to through their organization). This person may be able to do other things, like set up schedules for a study. They can see study participant information in the studies they have access to through their organization.

STUDY DEVELOPER - This is a study-scoped version of a developer. It’s not clear yet if it will be needed (coordinators might be able to configure everything about a study and we aren’t going to let outside developers muck about with app configuration).

ORGANIZATION ADMINISTRATOR - This is an administrator of an organization, that can create accounts. Those users (or the org administrator) edit an organization, including creating accounts in the organization. They or their users can in turn create studies that are sponsored by, and accessible to, all organization members.

The Problem (original issues that led to this design)

In adding Mobile Toolbox to Bridge, we’re encountering more complex authorization. We have roles like an organization administrator, who can create users who are members of their organization (but who cannot see any other kind of accounts, including study participants in their organization’s studies), and study designers, who can edit some of the things that a developer can edit…but only in the context of the studies they have access to.

...