Skip to main content

Users and Permissions

Data is the most important asset for all coScene users. While enabling users to efficiently use data, we also pay great attention to users' requirements for the security and confidentiality of their data assets. From day one, we have been designing and building a flexible, scalable, and configurable permission model to meet our customers' needs for confidentiality, security, and control.

coScene's current permission system fully references the best practices in the industry, taking into account the impact of RBAC and ABAC models on our application. At this stage, coScene's implementation is based on RBAC, but will gradually introduce features of ABAC in upcoming releases, ultimately achieving a flexible yet easy-to-understand permission setting model.

Organizations and Projects

As the permission container carriers of the application, coScene mainly divides various resources into two levels. The first level is the organization. All actual users of coScene should belong to a real group, which is reflected in coScene as an organization. The organization does not own actual data resources but has actual resource entities within the organization, such as equipment and personnel, and assigns roles to members at the organizational level.

The organization is also the owner of projects, and each organization can have any number of projects. Projects, as the container carriers for data generated by users and devices, are the second level of permission resource isolation system within coScene. Files and records produced by devices, events generated by devices and users, and the flow relationships between various requests all occur within the project.

Permissions and Resources

Based on the above permission system and principles, the coScene platform predefines various actions (Action) and policies (Policy) for all resources within the system and defines template roles, which are as follows:

Organization

  1. Organization Administrator: Can manage all resources and permissions within the organization
  2. Member: Can manage all data within the organization that members have permission to
  3. Read-only Member: Can read all data within the organization that members have permission to

Project

  1. Project Administrator: Can manage all resources and permissions within the project
  2. Member: Can manage all data within the project
  3. Read-only Member: Can read all data within the project

When a user has a role in a project, the user's role within the project will be prioritized. The only exception is the organizational administrator, who currently has the highest system permission, can access all projects, and will ignore the role settings within the project (if any).