RBAC Role Hierarchy Management via Dual Organization Structure
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The proliferation of roles in Role-Based Access Control (RBAC) systems leads to complex management and increased security risks due to the multiplication of roles exceeding the number of users, complicating authorization processes and potentially weakening security.
Innovation Solution
The introduction of an additional class of objects, organizations, to qualify roles and implement a dual hierarchy, along with the use of regular expressions in XACML to transcribe hierarchical relationships and policies, reduces the number of roles and enhances access control management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If precise access control is implemented using traditional RBAC, then authorization accuracy is improved, but the number of roles increases excessively, leading to management complexity and security risks
Solution Approach 1:
The patent introduces a hierarchical dimension to the RBAC model by organizing roles into multiple levels (e.g., global roles, local roles, composite roles). This hierarchical structure allows the system to manage access control with fewer role definitions while maintaining precise authorization, as roles can be composed and inherited across hierarchy levels rather than defining every permission separately.
Solution Approach 2:
The patent enables roles to serve multiple functions through inheritance and composition mechanisms. A single role can inherit permissions from parent roles and can be composed of multiple sub-roles, allowing one role to fulfill multiple authorization functions. This multi-functionality reduces the total number of roles needed while maintaining comprehensive access control coverage.
2Measurement precision
If the number of roles is increased to achieve precise access control, then authorization precision is improved, but management complexity increases and security is weakened
Solution Approach 1:
The patent segments the role hierarchy into manageable levels and components. By dividing roles into hierarchical levels (parent roles, child roles, composite roles) and allowing selective inheritance, the system maintains authorization precision while making role management more tractable through structured organization rather than flat, exhaustive role definitions.
Solution Approach 2:
The patent implements nested role structures where roles contain and inherit from other roles across multiple hierarchy levels. This nesting allows precise authorization to be achieved through layered role definitions, where complex authorization requirements are built by nesting simpler role definitions, reducing management complexity while maintaining precision.
3Ease of manufacture
If traditional RBAC is used, then implementation simplicity is maintained, but the number of roles exceeds the number of users, complicating management
Solution Approach 1:
The patent merges multiple role definitions into hierarchical role structures where parent roles and child roles share common permissions through inheritance. By combining role definitions across hierarchy levels and allowing role composition, the system reduces the total number of distinct role definitions needed while maintaining comprehensive access control coverage.
Solution Approach 2:
The patent makes roles universal through inheritance mechanisms, where a single role definition at a higher hierarchy level can serve multiple authorization purposes across different contexts and user groups. This multi-functionality reduces the quantity of roles needed while maintaining implementation simplicity through reusable role definitions.
Data Source
Figure 1
Figure 2~3a
Figure 3b
AI summary
The invention relates to a method for managing access control to a service, the method being implemented using a repository comprising: - user data; - role data organized according to a first hierarchy; - permission data; - organization data organized according to a second hierarchy; - data representing: ▪ at least one first relationship in which a user data element is associated with a role data element within an organization data element; ▪ at least one second relationship in which a role data element is associated with a permission data element and an organization data element; the method comprising the steps of: - for each second relationship, defining a first list comprising the role data elements from the repository that are hierarchically superior to the role data element of the second relationship;- For each first relationship, define a second list including the organization data from the repository that inherits from the organization data of the first relationship; - Define a rule that associates the permission data from the second list of said second relationship to access said service with a user data if said user data is associated with a role data from the first list in any of the organization data in the second list; - Receive a service access request, said access request including a user data, a permission data, and a role data; - For each first relationship of the user data in the access request: - Define a third list including the organization data of hierarchical orders higher than the organization data of said first relationship;- Define a fourth list in which the role data from the first relationship is associated with each organization data point from the third list; - For each rule previously defined: - Test if the role data point of the access request belongs to the first list; and - Test if the organization data point of the rule belongs to the fourth list; - If either test is positive, allow access to the service.