# Role-Based Access Control Model for Inter-System Cross-Domain in Multi-Domain Environment
## 6 Model Evaluation
### Security Analysis
#### 6.2.1 Model Confidentiality Analysis
Cardinality constraint; \[cardinality(sr,m)\wedge sr\in user\_authorization(u_{1})\wedge sr\in user\_authorization(u_{2})\wedge\ldots\wedge sr\in user\_authorization(u_{n})\left(n>m\right)\] (35)  
where \(cardinality(sr,m)\) means that the specific role \(sr\) can only be authorized to \(m\) users at most, and there is a cardinality constraint. This formula describes that the specific role \(sr\) is authorized to \(n\) users at the same time, and the number of authorizations exceeds the maximum number of cardinals \(m\). This shows that the cardinal constraint rule of the specific role is violated. **Proof that RBAC-IC does not meet Formula (35). **  
Assume that the specific role \(sr\) exists, and \(sr\) has cardinality constraints \(cardinality(sr,m)\); In the current state, no user has authorized \(sr\). At this time, if the domain administrator has authorized \(sr\) for no more than \(m\) users, the \(cardinality(sr,m)\) constraint is satisfied; That is \[cardinality(sr,m)\wedge sr\in user\_authorization(u_{1})\wedge sr\in user\_authorization(u_{2}) \wedge\ldots\wedge sr\in user\_authorization(u_{n})\left(n\leq m\right)\] (36) is established; If the number of users with \(sr\) is greater than \(m\), Formula (35) is valid; According to the pigeonhole principle [31], if \(m\) users have \(m+1\)\(sr\), it means that at least one user will have two identical \(sr\), but the user cannot authorize this \(sr\) again if he has \(1\)\(sr\). Therefore, the number of users with \(sr\) cannot be greater than \(m\); According to \(cardinality(sr,m)\), \(sr\) can only be authorized to \(m\) users at most, and no more than \(m\) users have \(sr\). Therefore, Formula (35) conflicts with cardinal constraint rules, and Formula (35) is valid; It can be proved that RBAC-IC does not meet Formula (35). \(\square\)  
3. Prerequisite constraint; \[prerequisite(sr_{1},sr_{2})\wedge sr_{2}\
otin user\_authorization(u)\wedge sr_{1} \in user\_authorization(u)\] (37)  
where \(prerequisite(sr_{1},sr_{2})\) indicates that the user must have the specific role \(sr_{2}\) before authorizing the specific role \(sr_{1}\), and \(sr_{1}\) has prerequisite constraints. This formula describes that the user \(u\) is authorized with \(sr_{1}\), but not with \(sr_{2}\). This indicates that the precondition constraint rule of the specific role is violated. Figure 10: There is a static mutex constraint between \(sr_{1}\) and \(sr_{2}\). The domain administrator \(da\) can only authorize one of \(sr_{1}\) and \(sr_{2}\) to the user, that is, only one of 1 and 2 processes can be executed. **Proof that RBAC-IC does not meet Formula (37). **  
Assume there is user \(u\), and specific roles \(sr_{1}\) and \(sr_{2}\), \(sr_{1}\
eq sr_{2}\), and \(sr_{2}\) is a prerequisite role of \(sr_{1}\);  
Follow these steps to authorize users,  
step1: Authorize \(sr_{2}\) to \(u\);  
step2: Authorize \(sr_{1}\) to \(u\);  
If step 1 is never executed and step 2 is directly executed, Formula (37) is established;  
According to the prerequisite of the specific role, the user must have authorized the specific role that has the prerequisite specific role. Therefore, step2 cannot be executed without step1;  
It can be proved that RBAC-IC does not meet Formula (37). \(\square\)  
Figure 11 shows an example of a prerequisite constraint.