...
The permission model will be permission-based, assigning a role vis-a-vis a specific target model (aka a “permission”);
These new permissions will still be assigned to a user (not modeled as an association between an Account record and any other record in the system…this is easier to implement but it means that permissions won’t be cascade deleted when the target objects are deleted, only when the account is deleted);
Organizations will principally be a means to communicate who can see whom in a multi-tenanted application. Accounts will be assignable to multiple organizations. Migrated accounts will be given permissions to the sponsored studies of that organization, and then going forward, further permissions will have to be added on a case-by-case basis;
Another option: a person who is a developer in an organization can create a study, which is automatically sponsored by the organization.
A person creates a study and owns it and absolutely no one else can see it until it is sponsored or shared with others.
Bridge roles are hierarchical (in behavior, not in implementation). Generally a user should have only one role vis-a-vis a model object. For example, being a
STUDY_DESIGNERimplies that you can read information about studies, like the auditor role. Every study designer does not also have to be an auditor.PI_AGENTcould be an example of an exception to this.Currently an appApp-scoped developer
and researcher should no longer have study-scoped permissions;
App-scoped admins can still probably do anything within their app;
System-scoped admins can still do anything in any app;
Otherwise, objects do not have any hierarchy (roles over an app do not imply roles over a study).
Use Cases
Use Case | |
|---|---|
Permissions changes should register for users without them having to sign out and sign back in again | If cached they need to be separate from the session in Redis. Otherwise, reading them on each request would meet this requirement. |
New admin account created with a sandbox in which studies can be created/edited that are not visible to others | When an account creates a study, it will be made the admin of that study. Searching for lists of studies will only return studies for which the caller has at least the AUDITOR role. |
“Sandbox” can be converted to real study, with additional users in specific roles for that study | Admin of a study can add additional users. We have not specified how we will make a study an “evaluation” study but that would need to be removable. |
Study is extended by creating a new study | Admin of the new study would need to copy over all the permissions from the old study. Bridge’s APIs should make this straightforward to do. |
Add someone to a study’s administration team | Add a permission (a role vis-a-vis the study) to that study. |
Remove someone from a study’s administration team | Remove a permission (a role vis-a-vis the study) from that study. |
Create similar authorization model for assessments | We should be able to expand this approach to any other model object we want to secure. |
...
Note that membership in an organization is also directly modeled in the database right now via the Account.orgMembership field. If we continue to model this in the database, it’ll it'll become an associative table and that association could specify the roles you gain as a member of the organization—however no one is asking for this so I don’t don't intend that we will do it.
...
| Code Block | ||
|---|---|---|
| ||
interface PermissionsService {
Set<Permission> getPermissionsForUser(String appId, String userId);
Permission addPermission(Permission permission);
void updatePermission(Permission permission);
void removePermission(Permission permissions);
Set<Permission> getPermissionsForObject);
void removePermission(Permission permissions);
Set<Permission> getPermissionsForObject(String appId, ObjectType type, String id);
// this delete cannot be cascaded by the database and must be done manually.
void deletePermissions(String appId, ObjectType type, String id);
/** Spring security will need a very focused method to check, for a
* given user and a given object, does the user have any of the required
* roles to perform the request. This method can fudge things like
* app-scoped permissions, too.
*/
boolean isAuthorized(AccountId accountId, ObjectType type, String objectId, Role... roles);
} |
...
Introduce a Membership associative table between Accounts and Organizations, and migrate the existing orgMembership value to this table. The table should be a simple associative table as roles are managed separately. But when we need to retrieve the list of members, or the organizations a person belongs to, it’s the object model we will examine.
Questions
We could design the permissions table so the objects are cascade deleted when object is deleted, otherwise it will need to be done manually (a method we must call).