Role Based Access Control (RBAC)

Overview:

Role-Based Access Control (RBAC) is an enhanced security feature introduced in Winmore to enable record-level access control at user level belonging to a particular user group.

Unlike the existing security model which restricts access only at the record template level, RBAC allows administrators to define conditional access policies that determine which specific records of a specific type a user belonging to a particular user group can access, based on defined attributes.

Business Benefits:

• Enables fine-grained, record-level access control. This essentially helps in controlling visibility of sensitive/irrelevant records within the same record type.

• Improves data security and governance.

• Provides a simple setup experience with minimal effort required to update and manage configurations.

Feature Configuration:

RBAC feature is controlled through a feature flag:

Feature Flag Name: Enable RBAC Policy

How to Enable:
Contact your Winmore implementation representative to request activation.

Functionality Details:

1. Accessing the Policy: Once the feature flag is enabled, a new “Policy” option will be available under Studio, allowing administrators to create and manage access policies for user groups.
   
2. Defining a New Policy: User can create security rule(s) for required record type and impose them on the specific user group(s). which gets applied on the users belonging to that group and matches the user attribute.
   
   • While configuring the policy condition, the user attribute is the pre-configured custom field in the user details page. Studio > Users and Groups > User details page (refer below snippet):
     
3. Example:
   1. Assume, there is a security policy defined as below:
      Record Type: Tender
      Record Attribute: Tender Ocean Pricing Bid Status
      Operator: Equals
      User Attribute: Tender Ocean Pricing Bid Status
      
   2. Say there is a user "rateai@winmore.app" who belongs to "Test RBAC" user group and for whom the custom field "Tender Ocean Pricing Bid Status" has been set as "Submitted":
      
       
   3. Behavior:

      1. When rateai@winmore.app logs in, the system restricts visibility of Tender records based on the defined policy.

      2. Since the user’s attribute value (Submitted) matches the Tender’s Pricing Status, the user will not be able to view those Tender records where the Pricing Status is Submitted.

      3. This restriction applies to all users who belong to the “Test RBAC” user group and whose corresponding user attribute value matches the Tender field used in the policy.

      4. Important Note on Operator Behavior: 

         • The behavior described above applies when the Operator is set to “Equals”.

         • If the same policy was configured with the “Not Equals” operator instead, then:

           • The user rateai@winmore.app would be able to view all Tender records except those where the Pricing Status is Submitted.
              

4. Rule Evaluation Logic:

   1. Within a single policy:

      • Multiple rules operate using an AND condition.
        

      • All rule conditions must be satisfied for the policy to apply.

   2. Across multiple policies:

      • If the same user group is associated with multiple policies, all policies must be satisfied.

   3. When a policy condition is satisfied:

      • The system grants both Read and Write permissions.

      • Write permissions include all the actions like Create, Update, and Delete.

Additional Details:

1. Only Admin user(s) will be able to define the RBAC policies.
2. RBAC supplements the existing template-level permission model; it does not replace it. 
3. RBAC doesn't replace existing security hierarchy functionality, where the security is managed within a tender(Price Inspector) at lane level. Whereas RBAC works at tender level visibility.
4. RBAC policies can currently be configured only for standard record types.
5. Records outside the policy conditions are not visible to the user.
6. User attribute fields must be preconfigured before being referenced in a policy.
7. Enabled User-ID as the selectable user attribute in Role Based Access Control (RBAC) policy. 
   When administrators create a policy using User-ID and associate it with a user group, the policy restrictions will automatically apply to all members of that group.
   For more information, please refer this page.

Known Limitations:

1. Policies do not distinguish between read-only and write access once conditions are met.

2. Currently, there is no option to choose between AND and OR conditions for rules within a policy, and across multiple policies.

3. Defining policies supported only at the user groups, not for the user teams.