Skip to content

Access Control in Liquidator

Jump to bottom
Nicolaj edited this page Aug 8, 2019 · 2 revisions

Introduction

Access control is used to selectively restrict access to various resources of Liquidator. Examples of resources that might be restricted by access control:

  • Which pages different users of Liquidator can access
  • Which functions are available to different users of Liquidator
    • This can determine which elements, like buttons and features, are available to the user on different pages.
  • What type of information different users should be able to
    • Create, Read, Update or Delete (CRUD operations)
  • Which specific instances of data models different users should be able to perform CRUD operations on. For instance, a company member/owner should only be able to do CRUD operations on financial transactions in a company he is part of.

To support all four of these types of restrictions, it is suggested to implement a combination of two access control models. The first three items in the list above can be solved by the use of Role-Based Access Control (RBAC), and the last item would be enforced by the use of Attribute-Based Access Control (ABAC).

Role-Based Access Control (RBAC)

The RBAC approach is a user-centric mechanism that restricts resource access based on attributing roles to users. Authorization is done by checking that the attributed role of the executing subject has the necessary permission policies affiliated with that role.

The limitation of this model is 'role explosion', which can happen when a finer granularity of access control is needed, for instance when securing instances of data by considering their association to the executing subject. This is the fourth described case in the list above, and serves an example of why Liquidator also need Attribution-Based Access Control (ABAC).

RBAC can be implemented in Django by using the native django.contrib.auth app with permissions and groups or by using specialization of the User model (for instance by specifying a Teacher and a Student model with different sets of model fields and permission sets).

Identified roles in Liquidator

At this time there are two roles identified in the Liquidator requirements:

  • Standard user: Should be able to create their own company, invite others, join other companies either as member or auditor, CRUD on financial transactions in companies they own or are a part of.
  • Superuser: Should have access to all parts of Liqudiator resources from the Django Admin Panel. (For maintenance purposes)

Source:

Attribution-Based Access Control (ABAC)

The ABAC approach is different to RBAC in that in stead of using pre-defined roles that carry a specific set of privileges associated with them, and to which subjects are assigned, ABAC uses a wider set of Boolean rules that evaluate several different attributes. The role attribution is only one such attribute, so that in this sense Role-Based Access Control can be viewed as a special case of an "atomic-valued" attribution. When many different attribute values are used to determine authorization, you have "set-valued" attribution.

The benefit of using ABAC is that it mitigates the problem described with RBAC where the relationships between instances of data and the executing subject (user) can lead to role explosion.

Examples

An example of how ABAC would work with authorization of CRUD operations on financial transactions. For a user to be able to CRUD a financial transaction, the following attributes has to be true:

  • The user is attributed the role of 'Standard user' (not auditor)
  • The user is attributed as a member of company XYZ Inc. in a member-company table.
  • The financial transaction is attributed to be associated to company XYZ Inc. (a N-1 relation)

In another case, for a user to be able to update or delete the company XYZ Inc. instance in Liquidator:

  • They have to be attributed as owner of company XYZ Inc.

In the scenario where Liquidator provide services to several hundreds (or thousands) of companies, keeping track of these relationships with application-wide role attribution (RBAC) would cause role explosion.

Identified access control attributions in Liquidator

There are 3 different attribution relationships identified in the Liquidator requirements:

  • Company owner: A Standard user which creates a company in Liquidator
  • Company member: A Standard user which joins a company by invitation as member.
  • Company auditor: A Standard user which joins a company by invitation as auditor.

Note: A company auditor is by default a Standard User so they are also able to create their own company.

Source:

What is a Company?

A company defines the current account (or context) of the application when it runs in the browser. Every time a user of the application signs in by authenticating themselves they will be dispatched to the authenticated part of the application where an initial company is selected and stored in the applications state.

If the user of Liquidator has just created their account, they will not have any companies in their profile and must create one (or join one by invitation) to get started with maintaining financial transactions. The selected company defines which financial transactions and aggregated information is shown to the user during runtime of the application.

What is an Auditor

An auditor is usually an external person of a company which sometimes needs to review financial statements and future estimations. It could for instance be an employee of a commercial bank which is assigned as the company's contact point. This role should only have read access to the application.

Clone this wiki locally