Task: RBAC - Model Design

[kbeaugrand]

Story: #2694

Description Define the structure of the RBAC model including roles, permissions, and hierarchical scopes, establishing relationships between them. Determine the parent-child relationships between scopes within the hierarchy.

[TLeoDev]

Story Reference

• Story: #2694

Introduction

This document outlines the structure of our system's RBAC (Role-Based Access Control) model, detailing the roles, permissions, hierarchical scopes, and their interrelationships.

RBAC Model :

Actions

• Description: Fundamental operations within the system, such as read, write, execute.
• Implementation: Defined in the Action class with attributes like Name and Description.

Roles

• Description: Collections of actions that define specific permissions.
• Implementation: The Role class includes a Name and a list of Actions.

Access Control

• Description: Associates roles with specific hierarchical scopes, defining where the permissions of a role are applicable.
• Implementation: The AccessControl class links a Role to a Scope (a string representing the hierarchical path).

Users and Groups

• Description: Users are associated with access controls, which define their permissions within various scopes. Groups also have access controls that apply to all their members.
• Implementation:
  • The User class includes Name and a list of AccessControls.
  • The Group class contains Name, a list of Members, and AccessControls.

Hierarchical Scopes

• Concept: Represent hierarchical paths in the system (e.g., "Client/CompagnieX/SiteA/Billing/deviceId").
• Parent-Child Relationships: Higher-level (parent) scopes include the permissions of their lower-level (child) scopes.
• Scope Management: Handled through an interface for creating, modifying, and deleting scope paths.

Examples

Scenario: Enterprise with Multiple Departments

• Context: Consider an enterprise with multiple sites, including 'Site A'. Within 'Site A', there are different departments like 'Secretariat' and 'Production'.
• Groups: Two groups are created: one for the 'Secretariat' department and another for 'Production'.

Role and Access Control Configuration

• Role: 'DeviceCommand_Execute' - This role allows executing commands on devices.

• Secretariat Group:

  • Members of this group are assigned an AccessControl linking the 'DeviceCommand_Execute' role with the scope "Secretariat".
  • This setup allows members of the 'Secretariat' to execute commands on devices labeled with the "Secretariat" scope.
  • They can, for instance, turn on and off connected lights within the 'Secretariat' area but are restricted from performing these actions on devices in the 'Production' area.

Hierarchical Scopes and Permissions

• Scope Assignment: Devices in different departments are assigned scopes based on their location and function. For example:

  • Devices in the 'Secretariat' department have the scope "Secretariat".
  • Devices in the 'Production' department have the scope "Production".

• Permission Limitation:

  • The 'Secretariat' group members cannot interact with devices in the 'Production' scope, as their access is limited to the "Secretariat" scope.
  • This design prevents unauthorized access while allowing flexibility within designated areas.

Conclusion

This example illustrates how the RBAC model can be effectively used to manage permissions in a complex environment. By assigning roles and scopes wisely, the system ensures security and operational efficiency, allowing specific actions in designated areas while preventing unauthorized access to sensitive equipment or areas.

[kbeaugrand]

@TLeoDev please review your previous comments regarding our internal discussions about the actions and access control managements

[TLeoDev]

Story Reference

• Story: #2694

Introduction

This document outlines the structure of our system's RBAC (Role-Based Access Control) model, detailing the roles, permissions, hierarchical scopes, and their interrelationships.

RBAC Model :

Roles

• Description: Collections of actions that define specific permissions.
• Implementation: The Role class includes a Name and a list of Actions.

Access Control

• Description: Associates roles with specific hierarchical scopes, defining where the permissions of a role are applicable.
• Implementation: The AccessControl class links a Role to a Scope (a string representing the hierarchical path).

Users and Groups

• Description: Users are associated with access controls, which define their permissions within various scopes. Groups also have access controls that apply to all their members.
• Implementation:
  • The User class includes Name and a list of AccessControls.
  • The Group class contains Name, a list of Members, and AccessControls.

Hierarchical Scopes

• Concept: Represent hierarchical paths in the system (e.g., "Client/CompagnieX/SiteA/Billing/deviceId").
• Parent-Child Relationships: Higher-level (parent) scopes include the permissions of their lower-level (child) scopes.
• Scope Management: Handled through an interface for creating, modifying, and deleting scope paths.

Examples

Scenario: Enterprise with Multiple Departments

• Context: Consider an enterprise with multiple sites, including 'Site A'. Within 'Site A', there are different departments like 'Secretariat' and 'Production'.
• Groups: Two groups are created: one for the 'Secretariat' department and another for 'Production'.

Role and Access Control Configuration

• Role: 'DeviceCommand_Execute' - This role allows executing commands on devices.

• Secretariat Group:

  • Members of this group are assigned an AccessControl linking the 'DeviceCommand_Execute' role with the scope "Secretariat".
  • This setup allows members of the 'Secretariat' to execute commands on devices labeled with the "Secretariat" scope.
  • They can, for instance, turn on and off connected lights within the 'Secretariat' area but are restricted from performing these actions on devices in the 'Production' area.

Hierarchical Scopes and Permissions

• Scope Assignment: Devices in different departments are assigned scopes based on their location and function. For example:

  • Devices in the 'Secretariat' department have the scope "Secretariat".
  • Devices in the 'Production' department have the scope "Production".

• Permission Limitation:

  • The 'Secretariat' group members cannot interact with devices in the 'Production' scope, as their access is limited to the "Secretariat" scope.
  • This design prevents unauthorized access while allowing flexibility within designated areas.

Conclusion

This example illustrates how the RBAC model can be effectively used to manage permissions in a complex environment. By assigning roles and scopes wisely, the system ensures security and operational efficiency, allowing specific actions in designated areas while preventing unauthorized access to sensitive equipment or areas.

[TLeoDev]

Some changes in the RBAC design (addition of the Principal concept) :

Story Reference

Story: #2694

Introduction

This document outlines the updated structure of our system's RBAC (Role-Based Access Control) model, detailing the roles, permissions, hierarchical scopes, their interrelationships, and the integration of a new Principal entity to unify the management of Users and Groups.

RBAC Model:

Story Reference

Story: As a system administrator, I want to define roles within the RBAC model to accommodate various user responsibilities, allowing for effective access control management. #2694

Introduction

This document outlines the updated structure of our system's RBAC (Role-Based Access Control) model, detailing the roles, permissions, hierarchical scopes, their interrelationships, and the integration of a new Principal entity to unify the management of Users and Groups.

RBAC Model:

(ici une image du nouveau diagramme UML avec les changements)

Roles

• Description: Collections of actions that define specific permissions.
• Implementation: The Role class includes a Name and a list of allowed Actions.

Access Control

• Description: Associates roles with principals, applying permissions across different hierarchical scopes.
• Implementation: The AccessControl class links a Role to a Principal and a Scope, defining where the allowed actions of a role are applicable.

Principals

• Description: Represents a unified entity that can be either a User or a Group, facilitating a central point of access control.
• Implementation: The Principal entity holds references to AccessControls, streamlining permission assignments for both users and groups.

Users and Groups

• Description: Users and Groups are now linked via the Principal entity, which simplifies the management of access controls.
• Implementation:
  • The User class includes Email, GivenName, and a Principal.
  • The Group class contains Name, Description... and a list of Members (users who are part of the group) , and his associated Principal.

Hierarchical Scopes

• Concept: Represent hierarchical paths in the system (ex : "IoTHubPortal/Michelin/Client/SiteA/Billing/*").
• Parent-Child Relationships: Higher-level (parent) scopes inherit the permissions of their lower-level (child) scopes.
• Scope Management: Handled through an interface for creating, modifying, and deleting scope paths.

Examples

Scenario: Enterprise with Multiple Departments

• Context: Consider an enterprise with multiple sites, including 'Site A'. Within 'Site A', there are different departments like 'Secretariat' and 'Production'.
• Groups: Two groups are created: one for the 'Secretariat' department and another for 'Production'.

Role and Access Control Configuration

• Role: 'DeviceCommand_Execute' - This role allows executing commands on devices.
  • Secretariat Group: Members of this group are assigned an AccessControl linking the 'DeviceCommand_Execute' role with the scope "Secretariat".
    • This setup allows members of the 'Secretariat' to execute commands on devices labeled with the "Secretariat" scope. They can, for instance, turn on and off connected lights within the 'Secretariat' area but are restricted from performing these actions on devices in the 'Production' area.

Hierarchical Scopes and Permissions

• Scope Assignment: Devices in different departments are assigned scopes based on their location and function, e.g., devices in the 'Secretariat' department have the scope "Secretariat"; devices in the 'Production' department have the scope "Production".
• Permission Limitation: The 'Secretariat' group members cannot interact with devices in the 'Production' scope, as their access is limited to the "Secretariat" scope.

Conclusion

This example illustrates how the updated RBAC model, with the integration of the Principal entity, can be effectively used to manage permissions in a complex environment. By assigning roles and scopes wisely, the system ensures security and operational efficiency, allowing specific actions in designated areas while preventing unauthorized access to sensitive equipment or areas.