# Enhancing Healthcare Security: A Unified RBAC and ABAC Risk-Aware Access Control Approach
## 4 Implementation of Proposed Model in Healthcare Scenario
### Role-Based Access Control Implementation  
RBAC provides a coarse-grained approach to control user identities, where access decisions are based on predefined user roles [36]. The RBAC is adopted as the foundational layer of the proposed model, which is mainly designed to authenticate user identities and pre-emptively filter out unauthorized resource requests, thereby improving system efficiency and performance. The most common way to implement RBAC is by manually integrating access control checks directly into the application code, adding condition-checking logic at various points. While suitable for small projects with limited user roles, this approach becomes difficult to maintain and scale as the application grows, leading to code duplication and decreased maintainability. To address these challenges and ensure better integration with other dynamic access control components, Aspect-Oriented Programming (AOP) was adopted as the preferred development paradigm. A sequence diagram illustrating the AOP of the RBAC is shown in Figure 3.  
AOP offers a unique advantage in developing a risk-aware RBAC system, making it the best fit for this research. It allows us to modularize cross-cutting concerns, such as logging, error handling, and security, and separate them from the central business logic. This decoupling of access control policies from the application code results in better code maintainability and extensibility. To maintain security in a risk-aware RBAC system, access control decisions need to consider real-time contextual data and risk factors. AOP's dynamic nature enables us to adjust access control policies during runtime, depending on the changing conditions. This dynamic policy enforcement ensures that access decisions are tailored to the current risk environment, thereby improving the system's security. AOP also served as the Policy Enforcement Point (PEP) in our integrated approach for the later ABAC model. The predefined AOP for the RBAC enables seamless integration with the rest of the ABAC components (PDP and PIP), which means once the request passes the role-based authentication/verification, it will redirect to the PDP instead of directly visiting the API. To implement user role verification/authentication with RBAC, a container class called a token pool was created to manage user roles. The class holds a HashMap objective, which will store user IDs and their tokens. The primary function of this class is to put the user ID and a unique UUID into the token pool, indicating that the user has logged in and providing the necessary user identity for future access control measures. For the authentication process, the system sends the token back to the user's browser once the user passes the login checks. The browser will store the token in the session storage for a limited time. When the user attempts to send a request to the back end, the system asks the user to send the token to identify the user's identity based on the received token. The user will receive a JSON object that includes their login status and token. There are four possible scenarios in which a user request may be rejected by the AOP layer. The request will be processed to further access controls once it passes all four checks:  
1. Absent Token: The token was not presented, and the user may not login yet. 2. Invalid Token: An invalid token was presented; the user may be signed out. 3. Expired Token: The token has expired; the user may need to login again. 4. Invalid Privilege: A valid token was presented. Figure 3: AOP of the RBAC of the proposed model. Once the RBAC layer in the proposed integrated model is designed, the next step is to determine the user roles and their corresponding permissions. The user's identity determines the operations they can perform (e.g., read, write, and delete) and the type of data they can access (e.g., medical records) in the system.