Granular RWX Details

 

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, making it suitable for organization 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

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, 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

 

Read

Write

Execute

Business Models and Monitors (i.e. storedModels)

  • Visualize

  • Edit [ Put / Patch ]

  • Create snapshots*

Snapshots (i.e. deployableModels)

  • Visualize

  • Edit [ Put / Patch ]

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

ModelMLC

  • Visualize

  • Edit [ Put / Patch ]

N/A

Jobs

  • Visualize

  • Edit [ Put / Patch ]

N/A

Runtimes

  • Visualize

  • Edit [ Put / Patch ]

  • Deploy to the runtime

  • Schedule jobs on the runtime

  • Reset engine

Notifications

  • Visualize

N/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.

Examples

Context tables.

Onboarded Models

Group

Onboarded Models

Group

Model A

GroupA

Model B

GroupB

Model C

GroupC

Users:

User

Group

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

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

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

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

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

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

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.