Page Comparison

...

We’re seeking a permissions model that will cover our current security capabilities while tackling new use cases, such as the ability to manage access to studies.

• The permission authorization model will be permissionrole-based, assigning a role vis-a-vis a specific target model (aka we’ll call this a “permission”);

• These new permissions will still be assigned to a user (not modeled as a separate table, not an association between to an Account record and or any other record in the system…this is easier to implement graft onto the existing system, but it means does mean that permissions won’t be cascade deleted by the database when the target objects are deleted, only when the account is deletedtheir associated user or model object is deleted (due to the use of non-SQL databases, this is often true in our system);

• 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.

  • Organizations continue to transitively give their members a role that allows them to see the organization’s sponsored studies. They could then ask to have more specific roles vis-a-vis one of those studies.

• 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_DESIGNER implies that you can read information about studies, like the auditor AUDITOR role. Every study designer does not also have to be an auditor. PI_AGENT could be an example of an exception to this.

  • App-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).

...