...
It simplifies administration by assigning [READ,WRITE,EXECUTE] Permissions to specific groups based on their responsibilities. This approach allows for lower level group access control, enabling administrators to extend the visibility, access and execution of ModelOp Center entities beyond their original onboarded groups.
RWX , is highly scalable , making which makes it suitable for organization organizations of all sizes. As the organization grows and evolves, RWX allows admins for the addition or modification of groups access privileges. This scalability ensures that Group access control remains manageable and adaptable to changing business requirements.
By assigning [READ,WRITE,EXECUTE] Permissions, RWX , restricts unauthorized access and prevents users from performing actions beyond their group access privileges. This principle of least privilege ensures that users only have access to the resources necessary to perform their tasks, limiting the impact of security breaches and internal threats.
...
Term | Definition |
|---|---|
GroupAccessPrivilege | A group access privilege entity is a POSIX Extended Access Control List (ACL) narrowed to group-level ownership. A GroupAccessPrivilege consists of: [ Collection, Owner, Group, Permissions ] |
Collection | The collection of Entities to which this GroupAccessPrivilege applies. |
Owner | The group that controls this GroupAccessPrivilege. |
Group | The group to which access is granted. |
Admin-user | End-user with admin privileges with access to all resources within ModelOp Center. Additional privileges:
|
Non-admin user | End-user without admin privileges, that can access only resources associated to the groups that given end-user belongs to and resources available through a given Read, Write or Execute GroupAccessPrivilege. No additional privileges:
|
Permissions | The set of granted permission. Available permissions: [READ, WRITE, EXECUTE] |
READ Permission | A user who has READ permissions will have view only access to the given entity. For example, READ access to a Business Model permits the user to see the Use Case or Model, and all of its relevant information , such as assets, documentation, jobs, test results, and associations. A user with READ permissions only cannot modify the given entity. |
WRITE Permission | A user who has WRITE permissions will have the ability to modify the given entity. For example, WRITE access to a Business Model permits the user to edit the information/metadata about the Business Model and add/edit assets, associations, and documentation. For a Model snapshot, a user with WRITE permissions may also add monitors. |
EXECUTE Permission | A user who has EXECUTE permissions will have the ability to run specific tasks for the given entity. For example, EXECUTE access to a Business Model permits the user to create a Snapshot (“version”) of the model. For a Snapshot, EXECUTE access allows the user to run tests/monitors, create jobs, and deploy models. |
...
| Read | Write | Execute |
|---|---|---|---|
Business Models and Monitors (i.e. storedModelsStoredModels) |
|
|
|
Snapshots (i.e. deployableModelsDeployableModels) |
|
|
|
Deployed Models |
|
| N/A |
Model Test Results |
|
| N/A |
ModelMLCModel MLCs |
|
| N/A |
Jobs |
|
| N/A |
Runtimes |
|
|
|
Notifications |
| /A
| N/A |
*If the snapshot is created through the Jupyter plugin, then the user must have write permissions, in addition to read and execute, to the stored model group. When a snapshot is created through the Jupyter plugin, the plugin updates the stored model with platform info, hence the need for write permissions.
**Only for Notification entity, when a new Notification is created, it will inherit the same group as the model it was created for. There might be instances when the user will NOT belong to the group assigned to the Notification, but they will have to have write permissions for the model’s group on the Notification collection.
Please note that for all other objects, the following rule still applies: on newly created entities, users can only assign groups they actually belong to, and not been given permissions to.
Examples
Context tables.
Onboarded Models | Group |
|---|---|
Model A | GroupA |
Model B | GroupB |
Model C | GroupC |
...
User | READ Model A | READ Model B | READ Model C | Rules description |
|---|---|---|---|---|
Alice | ✅ | ❌ | ❌ |
Result:
|
Bob | ✅ (Granted by RWX - row 1) | ✅ | ❌ |
Result:
|
Charley | ❌ | ✅ (Granted by RWX - row 2) | ✅ |
Result:
|
...