# Enhancing Healthcare Security: A Unified RBAC and ABAC Risk-Aware Access Control Approach
## 3 Risk-Aware RBAC and ABAC Model: Proposed Approach
These APIs are not openly accessible; instead, they are typically protected by the PEP, which acts as the initial access checkpoint within the system. The PEP intercepts all incoming requests and evaluates them against pre-defined access control rules before forwarding them to internal services. This enforcement mechanism ensures that unauthorized access attempts are blocked at the earliest possible stage. In our proposed model, this behavior is implicitly represented through the inclusion of the PEP at the interface between the user and the internal system components. While the API itself is not visually presented in the diagram, its function is inherently embedded within the PEP layer, which reflects how API access is managed and secured in real-world healthcare systems. If a user attempts to access a resource or API without possessing the appropriate role privileges, the request is denied immediately, and it does not proceed to the subsequent layers. Although there is no distinct branch showing the early blocking of unauthorized requests at the RBAC layer in the diagram, this behavior is implicitly enforced through the PEP. Requests that do not meet the required role privileges are terminated at this stage and do not proceed to the subsequent risk and attribute evaluation layers. This early rejection mechanism helps reduce system load, improves resource utilization, and enhances performance by preventing unnecessary evaluations of invalid requests at deeper layers. * **Layer 2: Risk-Based Access Control (RiBAC) Layer:** The second layer incorporates a Risk Engine, which enables real-time contextual awareness and dynamic decision-making. This layer does not enforce access decisions on its own but plays a critical supporting role by evaluating contextual and behavioral factors, including user activity  
Figure 1: Proposed risk-aware RBAC and ABAC model. history and behavioral patterns, the sensitivity of the requested resource, access time, location, device, and environmental factors. These elements are used to calculate a dynamic risk score, which represents the trustworthiness of a specific access request in the given context. This risk score is then passed as an enriched attribute to the next layer (ABAC), allowing for adaptive and fine-grained policy enforcement that reflects the dynamic security posture of the system. * **Layer 3: Attribute-Based Access Control (ABAC) Layer:** At the core of the proposed model lies the ABAC layer, which is responsible for making the final access control decision. This layer is anchored by the Policy Decision Point (PDP), which evaluates policies based on a combination of static attributes (e.g., user role, resource type, action) and dynamic risk values received from the RiBAC layer. The ABAC engine retrieves relevant policies from a policy repository, often managed by the Authorforce PDP engine, and collects additional attribute data from the Policy Information Point (PIP). The policy evaluation process considers both static and dynamic inputs, enabling context-sensitive, fine-grained access control decisions that reflect the system's current risk environment. Together, these three layers establish a comprehensive and hierarchical access control model. The RBAC layer enforces baseline access eligibility, the RiBAC layer introduces dynamic risk intelligence, and the ABAC layer applies granular, adaptive policies to determine the final authorization outcome. This layered architecture enhances both security and system efficiency by combining the strengths of traditional access control models with modern context- and risk-aware mechanisms. The flow of access requests through RBAC, RiBAC, and ABAC involves a structured process aimed at ensuring secure and appropriate access within a system. Initially, RBAC defines access based on predefined roles to determine whether a user's role aligns with the requested target (API).