Overview

RWX is a widely adopted access control model that provides a structured approach to managing and enforcing access rights within ModelOp Center.

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 which makes it suitable for 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.

RWX privileges management is available only for Administrators.

Terminology

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: Able to manage Model Life Cycles. Able to manage RWX Permissions.
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: Can’t manage Model Life Cycles. Can’t manage RWX Permissions.
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.

RWX Rules

	Read	Write	Execute
Business Models and Monitors (i.e. StoredModels)	Visualize	Edit [ Put / Patch ]	Create snapshots*
Snapshots (i.e. DeployableModels)	Visualize	Edit [ Put / Patch ] Add Monitors	Execute monitors Deploy [POST DeployedModels] Create jobs (scoring or metric) and re-run jobs
Deployed Models	Visualize	Edit [ Put / Patch ] Un-Deploy	N/A
Model Test Results	Visualize	Edit [ Put / Patch ]	N/A
Model MLCs	Visualize	Edit [ Put / Patch ]	N/A
Jobs	Visualize	Edit [ Put / Patch ] Re-run jobs	N/A
Runtimes	Visualize	Edit [ Put / Patch ]	Deploy to the runtime Schedule jobs on the runtime Reset engine
Notifications	Visualize	Edit [ Put / Patch ] Create [ Post ]**	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 objects, 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

Users:

User	Group
Alice	GroupA
Bob	GroupB
Charley	GroupC

Example #1 - READ Permission

Having the next Group Access Privilege table, and using the above context tables as reference:

Row	Collection	Owner	Group	Permissions
1	StoredModels	GroupA	GroupB	[READ]
2	StoredModels	GroupB	GroupC	[READ]

If the next users log-in into ModelOp Center, they will be able to see the next Models.

User

READ Model A

READ Model B

READ Model C

Rules description

Alice

✅

❌

Alice belongs to GroupA.
Alice is only able to see StoredModels from the only group she belongs to.
Model A is the only StoredModel associated to GroupA.

Result:

Alice only see Model A after logging in to ModelOp Center.

Bob

✅ (Granted by RWX - row 1)

✅

❌

Bob belongs to GroupB.
Model A is the only StoredModel associated to GroupA.
Model B is the only StoredModel associated to GroupB.
Bob is able to see StoredModels from the group he belongs to (GroupB) and also due to the RWX READ permission from RWX Table as the owned by Group B, Bob is able to see StoredModels from Group A as well.

Result:

Bob is able to see Model A and Model B after logging-in into ModelOp Center.

Charley

❌

✅ (Granted by RWX - row 2)

✅

Charley belongs to GroupC.
Model B is the only StoredModel associated to GroupB.
Model C is the only StoredModel associated to GroupC.
Charley is able to see StoredModels from the group he belongs to (GroupC) and also due to the RWX READ permission from RWX Table as the owned by Group C, Charley is able to see StoredModels from Group B as well.

Result:

Charley is able to see Model B and Model C after logging-in into ModelOp Center.

Example 2 - WRITE Permission

Having the next Group Access Privilege table, and using the above context tables as reference:

Row	RWX Table	Owner	Group	Permissions
1	StoredModels	GroupA	GroupB	[READ,WRITE]
2	StoredModels	GroupA	GroupC	[READ,WRITE]
3	StoredModels	GroupC	GroupA	[READ,WRITE]
4	StoredModels	GroupC	GroupB	[READ,WRITE]

If the next users log-in into ModelOp Center, they will be able to write/update the next Models.

User

[READ,WRITE] Model A

[READ,WRITE] Model B

[READ,WRITE] Model C

Rules description

Alice

✅

❌

✅ (Granted by RWX - row 3)

Alice belongs to GroupA.
Alice is able to READ,WRITE,EXECUTE:
- Model A (She belongs to Group A)
Alice is able to READ,WRITE:
- Model C (due to RWX rule, row 3)
Result:

Alice is able to WRITE (Modify) Model A and Model C after logging in to ModelOp Center.

Bob

✅ (Granted by RWX - row 1)

✅

✅ (Granted by RWX - row 4)

Bob belongs to GroupB.
Bob is able to READ,WRITE,EXECUTE:
- Model B (He belongs to Group B )
Bob is able to READ,WRITE:
- Model A (due to RWX rule, row 1)
- Model C (due to RWX rule, row 4)

Result:

Bob is able to WRITE (Modify) Model A , Model B and Model C after logging in to ModelOp Center.

Charley

✅ (Granted by RWX - row 2)

❌

✅

Charley belongs to GroupC.
Charley is able to READ,WRITE,EXECUTE:
- Model C (He belongs to Group C ).
Charley is able to READ,WRITE:
- Model A (due to RWX rule, row 2)

Result:

Charley is WRITE (Modify) Model A and Model C after logging-in into ModelOp Center.

Example 3 - EXECUTE Permission

Having the next Group Access Privilege table, and using the above context tables as reference:

Row	RWX Table	Owner	Group	Permissions
1	DeployableModels	GroupA	GroupB	[READ,EXECUTE]
2	DeployableModels	GroupA	GroupC	[READ,EXECUTE]
3	DeployableModels	GroupC	GroupA	[READ,EXECUTE]
4	DeployableModels	GroupC	GroupB	[READ,EXECUTE]

If the next users log-in into ModelOp Center, they will be able to Execute jobs (scoring and metrics) jobs against the next Models.

User

[READ,EXECUTE] Model A

[READ,EXECUTE] Model B

[READ,EXECUTE] Model C

Rules description

Alice

✅ + WRITE (Because Alice belongs to group A)

❌

✅ (Granted by RWX - row 3)

Alice belongs to GroupA.
Alice is able to READ,WRITE,EXECUTE:
- Model A (She belongs to Group A)
Alice is able to READ,EXECUTE:
- Model C (due to RWX rule, row 3)
Result:

Alice is able to EXECUTE jobs from Model A and Model C after logging in to ModelOp Center.

Bob

✅ (Granted by RWX - row 1)

✅ + WRITE (Because Bob belongs to group B)

✅ (Granted by RWX - row 4)

Bob belongs to GroupB.
Bob is able to READ,WRITE,EXECUTE:
- Model B (He belongs to Group B )
Bob is able to READ,EXECUTE:
- Model A (due to RWX rule, row 1)
- Model C (due to RWX rule, row 4)

Result:

Bob is able to EXECUTE jobs from Model A , Model B and Model C after logging in to ModelOp Center.

Charley

✅ (Granted by RWX - row 2)

❌

✅ + WRITE (Because Charley belongs to group C)

Charley belongs to GroupC.
Charley is able to READ,WRITE,EXECUTE:
- Model C (He belongs to Group C ).
Charley is able to READ,EXECUTE:
- Model A (due to RWX rule, row 2)

Result:

Charley is EXECUTE jobs from Model A and Model C after logging-in into ModelOp Center.

Granular RWX Details

Overview

Terminology

RWX Rules

Examples

Example #1 - READ Permission

Example 2 - WRITE Permission

Example 3 - EXECUTE Permission