MyDataWiz Identities, users, user groups, group resources, and roles.

In MyDataWiz every unique email address is treated as a unique idenity that is a user. Users have a Role that is a permission or role realated to the company. Users have a permission associated to a Group. Groups are intended to be teams. Groups have Permissions associated to a Resources. A Resources can Owned by one Group. A Group can share a resource.

Identities: Every unique email address is treated as a unique identity known as a User.

Groups: A Group is a collection of Users assigned specific Permissions related to specific Resources.

Roles: An Idenity has a Role related to the company. In MyDataWiz, Role identifies what operations a user can perform without membership in an entity.

Permissions: A Permission is the actions an Identity can perform on a entity.

Resources: A Resource is any construct that is not an Identity, or Permission.

Repos: A Repo is a Resource.

To simplify things we have made the decision that:

1. Roles will be used when administring resources like: Company, Groups, Repos.
2. Groups will be used when administering resources like: Repos
3. Users will be assigned pre-defined Roles.
4. Groups will be assigned permissions related to Resources not managed by Roles.

Default Roles for Users

// List of default roles.  Roles can be assigned to users.
// Difference between Roles and Permissions.
//    A Role is federated actor.
enum UserRole {
  roleNone                 // User is either new or inactive, or does not have a role assigned.
  roleGroupRead            // User can read all groups they belong to.
  roleGroupWrite           // User can read/write all groups they belong to.
  roleGroupAdmin           // User can read/write/delete all groups they belong to.
  roleCompanyRead          // User can read all company configuration.
  roleCompanyWrite         // User can read/write company global configuration.
  roleCompanyAdmin         // User can read/write/delete company configuration, default first user
  roleAdmin                // MyDataWiz internal Super User.
}

roleNone:

• User can update their profile, and address.

roleGroupRead:

• User has all roleNone privileges and ...
• User can read group resources that they are members of.
• User can invite new Users.

roleGroupWrite:

• User has all roleGroupRead privileges and ...
• User can write group resources that they belong to.
• User can add new Users to groups they belong to.
• User can manage Repos and access permissions.

roleCompanyRead:

• User has all roleGroupRead privileges and ...
• User can read all company and group resources.

roleCompanyWrite: User has all roleGroupWrite privileges and ... User has all roleCompanyRead privileges and ... User can write all company and group resources.

Default Groups for Users

// Common teams / groups we expect to find and support
const groups = [
  { name: 'Data Engineering', description: 'We ingest, move, condition, serve and govern data.' },
  { name: 'Data Platform', description: 'We build data agnostic infrastructure and services.' },
  {
    name: 'Data Analytics',
    description: 'We analyze, model, visualize data for products and features.',
  },
  { name: 'Customer Success', description: 'We visulize data to meet customer needs.' },
  {
    name: 'Data Science',
    description: 'We build and train models to personalize and recommend.',
  },
  {
    name: 'Product Engineering',
    description: 'We build product and features services that both produce and consume data.',
  },
];

Example: User, Groups, and Repos

A User (identity) has a permission related to a Group membership. A Group has a permission related to a Repo (resource). A Group can read, write or have no access to a Repo.

Example: User Managing a Group

A User (identity) has a permission related to a Group (resource). A User can be a Group Admin, or simply a member.

Permissions

Permissions granted are aligned with ReST APIs.

• No Permission: Access Denied
• Read Permission: GET
• Write Permission: POST, PUT, DELETE

Account Root User

The User who initial creates the account is considered to be the Root User and is associated to the roleCompanyAdmin role. The Root User can:

• Invite other users to join the Company.
• Assign other users to Groups and and Roles.
• Create, Modify, Delete Groups
• Create, Modify, Delete Company wide entities.

Users (Identity)

User's invited to join the Company are assigned to the default role of roleNone, which means by default they have no permissions, and do not belong to any groups. Once the User has logged in once and their identity confirmed then the user can become Group members and consequently have roles and permissions in accordance to the group.

User Groups

Groups are collections of users that have the same role for a collection of resources.

Example: Multiple teams different or competing roles.

We have three teams: Data Engineering Team, and Data Analytics Team. Because these teams work on their respective domains, they tend to have their own source code repos (a resource), in which they are the definitive owners of and are responsible for (a permission).

Consequently we create two groups, named Data Engineering, and Data Analytics respectively. In each of these groups we assign repos (resources) the team is resonsible for.

Data Engineering Data Engineering gets: ETL_repo.git, datawarehouse_repo.git, and dataset_repo.git, with the role roleWrite which gives them permission to read, write, and delete information in this group.

Data Analytics Data Analytics gets: report_repo.git, dataset_repo.git, with the role roleWrite, which gives them permission to read, write, and delete information in this group.

Data Engineering and Data Analytics work closely together, so the Data Engineering team provides roleRead to Data Analytics to facilitate collaboration. Similarly, Data Analytics provides roleRead to Data Engineering. Note that the two groups share some resources in this example in which they both have the permission roleWrite to. Access defaults to the highest level access the group has permission for a given resource.

Example: CompanyAdmin

Roles

A Role is a persona that a federated user can act through to have permissions of that persona for the duration they are acting in that role. A Role choice should be made at Login time, so that the identity can act as that persona for that login instance.

Default Roles

When to Assign a User a Role, vs. assigning a User to a Group with a Role.

By default a User is assigned the roleNone role, and has permissions to read, write, or delete their profile. No further permissions are granted by default.

When to create a Role vs. a Group.

When to create a Group vs. a Role.

Concepts

Consider the following heirarchy of teams in a Company. Notice how Team's responsibility is divided in different ways, depending on the team. We assume the code repo ownerships may also be divided according to team structures. We also assume that we would like to share our data models along these team structures.

The goal is not to mirror the company reporting directory, but to leverage the reporting structure to create self managing groups with logical owners to manage responsiblity, and access to data models.

.
└── Root
    ├── CTO
    │   ├── DataAnalytics
    │   │   ├── ProductA_Model1
    │   │   ├── ProductA_Model2
    │   │   ├── ProductB_Model1
    │   │   └── ProductB_Model2
    │   ├── DataEng
    │   │   ├── ProductA_Events
    │   │   ├── ProductB_Events
    │   │   ├── Service_AB_ETL
    │   │   ├── Service_AC_Events
    │   │   └── Service_BC_ETL
    │   ├── DataPlatform
    │   │   ├── DataService1
    │   │   ├── DataService2
    │   │   └── DataService3
    │   ├── DataSci
    │   │   ├── ProductA_Insights1
    │   │   ├── ProductA_Insights2
    │   │   ├── ProductB_Insights1
    │   │   └── ProductB_Insights2
    │   ├── FeatureEng
    │   │   ├── ProductA_UI_Feature1
    │   │   ├── ProductA_UI_Feature2
    │   │   ├── ProductB_UI_Feature1
    │   │   └── ProductB_UI_Feature2
    │   └── PlatformEng
    │       ├── ServiceA
    │       ├── ServiceB
    │       └── ServiceC
    ├── VP_CustomerSuccess
    │   ├── CustomerSuccess_ProductA
    │   │   ├── ProductA_Region1
    │   │   └── ProductA_Region2
    │   ├── CustomerSuccess_ProductB
    │   │   ├── ProductB_Region1
    │   │   └── ProductB_Region2
    │   ├── External_Customer1_ProductA
    │   ├── External_Customer1_ProductB
    │   ├── External_Customer2_ProductA
    │   └── External_Customer2_ProductB
    └── VP_Product
        └── Product
            ├── ProductA_Feature1
            ├── ProductA_Feature2
            └── ProductB

The axioms are:

• Companies have teams
• Teams have managers.
• Managers are responsible for their teams, or may delegate responsibility.
• Companies have resources.
• Resources are managed by teams.
• Teams are Groups and Group membership is maintained by delegated members.
• A Group is responsible for a Resource. (Owner).
• A Group Owner may share a Resource (Write/Read) with other Groups.
• A Group may be organized in a heirarchy.
• Groups have: a Parent, Children, Owners, Users, and Resources with permissions.

Roles

1. No Group Membership (New or retired User.)

• May update their profile.

2. Group Member

• May access resources in accordance to assigned resource permissions.

3. Group Owner

• May manage all groups in their heirarchal Children, but not Parent Group.
• May create children and delegate Ownership.
• May share Resources with assigned Permissions to any other Group.

Default Groups

Be default new users do not belong to any group, and do not have any prividges.

The default list of groups are below.

  .
  └── Root
      ├── CustomerSuccess
      ├── DataAnalytics
      ├── DataEngineering
      ├── DataPlatform
      └── PlatformEng

The initial user belongs to the Root group be default, and can manage the pre-created sub-groups by inheritance.

Scenarios

• New User, new Company, initial sign-up.

  • Persona: Any.
  • Conditions:
    • Company does not pre-exist
    • Company has a unique domain and email domain.
    • Persona can grant access to Repo resources.
  • First user gets roleCompanyAdmin by default.
  • Condition Failure: User is informed of existing roleCompanyAdmin users.

• Invite new users to an existing Company.

  • Persona: Any User with matching email Domain belonging to a group.
  • Conditions:
    • roleGroupRead or higher
    • Must be a Group member.

• Assign Users to an existing Group.

  • Persona: Group Owner
  • Conditions:
    • Can only assign Users to Groups they own or are in their hierarchy.

• Group Management.

• Persona: Group Owner

• Conditions:

  • Can Create/Modify/Delete Groups they own, or Child Groups.
  • Groups must have no Users, or Resources to be deleted.
  • Child Groups can be re-assigned a new Parent.

• Group Resource Management.

  • Persona: Group Owner
  • Conditions:
    • Can add un-owned resources.
    • Can share Owned resources with permission to any group, including different Company Group.
    • Can transfer Ownership to any group.

• Group Members.

  • Persona: Group Member
  • Conditions:
    • Can access Group Resources with assigned permission.
    • Can view Group Ownership, Child/Parent relationships, and Shares.

Implementation

User

• role [roleNone|roleGroupRead|roleGroupWrite|roleCompanyRead|roleCompanyWrite|roleAdmin]

• where:

  • roleNone:
    • no special roles.
    • by default access is denied.
  • roleGroupRead:
    • ability to view group configuration
    • access group resources with specified permissions.
    • default for group members.
  • roleGroupWrite:
    • inherits roleGroupRead privledges
    • ability to create Group shares.
    • ability to update group attributes.
    • default for group owners
    • problem is multiple owners.
  • roleGroupAdmin:
    • inherits roleGroupWrite privledges
    • group owner for all groups User is a member of.
    • default for parent group owner.
    • problem is parentage
  • roleCompanyRead:
    • inherits roleGroupAdmin privledges
    • ability to read all configuration in company.
  • roleCompanyWrite:
    • inherits roleCompanyRead privledges
    • ability to create|modify|delete all groups in the company.
    • problem is parentage
  • roleCompanyAdmin:
    • inherits roleCompanyWrite privledges
    • super user for a company.
    • problem is multile owners.
  • roledAdmin:
    • MyDataWiz site super user.

Implementation ideal

Problem: multiple references to same table is not allowed in MySql see: https://github.com/prisma/prisma/discussions/3960

User

• groups Group[]
• role []
• isOwner Group[]

Group

• owner User[] // list of Users with ownership. Owner must also be a member.
• member User[] // list of Users who are members.
• child Group[] // list of Groups who are children.
• parent Group // The single Group is is the parent.
• shares GroupHasShare[]

GroupHasShare <-- Day 2 implementation >

• owner Group // Single Group owner
• sharedWith Group // Single Group per share
• access [read|write] // Single permission per share
• company Companys[] // Company belongs to