# Role-Based Access Control Model for Inter-System Cross-Domain in Multi-Domain Environment
## 5 Case Analysis
### Design of Platform Access Control Model
#### 5.2.4 User's Authorization  
Design and authorization of users is shown in Table 4. RBAC-IC has three ways of authorizing the user a specific role. Users can be authorized multiple roles of a system in their domain, as shown in Figure 9. For example, U1 can produce three-piece cans and two-piece cans, so it is authorized SR1 and SR2 of the production management information system. Users also can be authorized to have a specific role for multiple systems in their domain, as shown in Figure 9. For example, U2 can be the sales executive and treasurer at the same time, so it is authorized SR8 and SR11 (assuming constraints are met). Users can be authorized specific roles in other domains, as shown in Figure 9. For example, U3, the printing staff in the outsourcing domain, needs to carry out printing according to the data of three-piece cans in the production domain, and thus, it can be authorized SR4.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Serial Number** & **Category** & **Operation** & **System** \\ \hline P1 & Data of three-piece cans & Input & Production \\ P2 & Data of three-piece cans & Read & Production \\ P3 & Data of two-piece cans & Input & Production \\ P4 & Data of two-piece cans & Read & Production \\ P5 & Production report of product A & Publish & Production \\ P6 & Production report of product B & Publish & Production \\ P7 & Sales data & Input & Sales \\ P8 & Sales data & Read & Sales \\ P9 & Sales report & Publish & Sales \\ P10 & Financial statement & Publish & Finance \\ P11 & Financial statement & Audit & Finance \\ P12 & Financial report & Publish & Finance \\ \hline \hline \end{tabular}
\end{table}
Table 2: Design of permissions.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Serial Number** & **Name** & **Abstract Role** & **Permission** & **Domain** & **System** & **Valid Time** \\ \hline SR1 & Production staff of three-piece cans & AR1 & P1, P2 & Production & Production & +\(\infty\) \\ SR2 & Production staff of two-piece cans & AR1 & P3, P4 & Production & Production & +\(\infty\) \\ SR3 & Production Supervisor & AR2 & P5, P6 & Production & Production & \(\infty\) \\ SR4 & Outsourced printing staff & AR1 & P1 & Production & Production & 2022-07-05T23-59-59Z \\ SR5 & Printing staff & AR1 & P1, P2 & Outsourced & Production & +\(\infty\) \\ SR6 & Production Executive & AR2 & P5 & Outsourced & Production & +\(\infty\) \\ SR7 & Sales staff & AR3 & P7, P8 & Administrative & Sales & +\(\infty\) \\ SR8 & Sales Executive & AR4 & P9 & Administrative & Sales & +\(\infty\) \\ SR9 & Accountant & AR5 & P10 & Administrative & Finance & +\(\infty\) \\ SR10 & Auditor & AR6 & P11 & Administrative & Finance & +\(\infty\) \\ SR11 & Treasurer & AR7 & P12 & Administrative & Finance & +\(\infty\) \\ \hline \hline \end{tabular}
\end{table}
Table 3: Design of specific roles.  
When authorizing specific roles to users, this will be limited by the constraint. After having already authorized SR3 to U1, authorizing SR3 to U4 will be denied because SR3 can only authorize one user at most. This is allowed when authorizing SR3 for U1, which already has the prerequisite role SR1 or SR2 required by SR3, but cannot authorize SR8 to U5 because U5 has not authorized the prerequisite role SR7 required by SR8, which violates prerequisite constraints. SR9 has been successfully authorized for U6, so continuing to authorize SR10 for U6 would be rejected because the two specific roles are mutex.