The need for a trusted environment in which only the authorized users are permitted to access data is of utmost importance in e-health services. Inadequate access control enforcement mechanisms are a blocking factor for the adoption of cloud systems, especially when sensitive data are stored and exchanged, as in the case of the health care domain.
Logical Access Control – How does it work?
The ASCLEPIOS framework is a security and privacy-by-design framework for accessing and handling medical data. One of the core aspects in ASCLEPIOS is logical access control to data. Logical access control is defined as “restricting virtual access to data; it consists of identification, authentication, and authorization protocols utilized worldwide to protect hardware from unauthorized access, including password programs, smart cards, or tokens to identify and screen users and access levels” [1].
At this point we should clarify that authorization should not be confused with authentication. Authentication deals with the problem of proving the identity of a natural person or a system entity that aims to interact with a resource, while authorization deals with the problem of providing logical access control to these resources.
And now back to logical access control; The logical access control is always bound to specific actions that the natural-person/systemic entity (from now on, called “subject”) wishes to perform over specific resources, i.e. discover, read, creating, edit, delete, and execute.
These resources belong administratively to organisational entities. These organisations are responsible to provide proper policies that dictate the Permit or Deny of the actions mentioned above. If the subject that wants to perform an operation with the resource satisfies the authorization policy established by the resource owner, then the subject is authorized to perform the desired operation on that resource.
Access Control Mechanisms
Practically, when we refer to an Access Control Mechanism (a.k.a. ACM) we refer to three distinct aspects:
- The way the concepts subject, object, action, environmental context and authorization policy are modelled and serialized
- The way the policy evaluation of Permit/Deny works (i.e. the signaling that has to be performed)
- The functional and the non-functional requirements that are promoted by the specific ACM (i.e. central access control entity).
In ASCLEPIOS we tried to enhance the access control mechanisms that can be used in the healthcare by defining and evaluating contextual information (e.g., the identity of a user, her role, patterns of access, connection type, etc.) and attributes that characterize sensitivity levels of data. ABAC (Attribute-Based Access Control) is an access control mechanism that uses attributes and policies that make use of these attributes. Policies are expressed as boolean rule sets that can evaluate many different attributes before allowing access. Therefore, ABAC does not need capabilities (operation/object pairs) to be directly assigned to subject requesters or to their roles or groups before the request is made. IBAC and RBAC can be seen as special cases of ABAC, with IBAC using the attribute of “identity” and RBAC using the attribute of “role”.
Most notable implementations of the ABAC paradigm are the eXtensible Access Control Markup Language (XACML) and the Next Generation Access Control (a.k.a. NGAC).
The ASCLEPIOS Context-Aware Authorisation Engine
The cornerstone of ASCLEPIOS Context-Aware Authorization Engine is the XACML-based Balana ABAC engine, enhanced by an identity management scheme that abstracts the extraction of authentication info. Hence the Context-Aware Authorization Engine is efficiently combining OpenIDConnect signalling for user authentication with Identity Extraction, and ABAC Policy Enforcement for user authorisation to access resources (including attribute-based encryption/decryption keys). The following figure provides an overview of the access control flow and the involved components.
Figure 1: ASCLEPIOS Access Control Flow
Initially, a user performs a request to access a specific resource. Before the evaluation, the request is intercepted by an authentication filter that is bound to the application. The role of the authentication proxy is not only to extract the identity (many times called principal-id) but to fetch a set of claims (i.e. attributes) that are verifiably associated with the user per se. For the Access Control enforcement in ASCLEPIOS, KeyCloak has been used as the authentication proxy.
These attributes are electronically signed by the OIDC server. Upon identity extraction, the signed claims along the initial request are intercepted by the PEP element. The implementation of the PEP element is also bound to the code base of the application. The PEP will forward the request and the extracted attributes to the PDP, which is the actual inference engine.
You can find details along with a more advanced flow that also facilitates the sharing of ABE keys in deliverable D3.3 of ASCLEPIOS.
References
1. https://www.identiv.com/community/2020/08/06/whats-the-difference-between-logical-access-control-and-physical-access-control/ (last access 18/01/2021)
Featured Image by Markus Spiske on Unsplash