User authorization

Background

There is a long, gnarly, and branching history of trying to describe and implement a complete and coherent scheme to control access to things. Cryptography to protect access to information, physical security to protect access to spaces, forts and walls to protect access to lands, etcetera, etcetera, and so forth. Standards, best practices, and trade secrets exist around all of them, as does on-going research: perfect security is yet to be found.

Humans are generally the weakest link...

Along with authentication — do you have a key to get in the door? — is authorization: what can you do once you get inside?

Introduction

Authorization is the process of determining whether the user behind an incoming request is allowed to execute the request. This process takes place after the user is successfully identified and authenticated.

Role-based access control (RBAC)

Role-based access control (RBAC) mechanism, which enables you to authorize users by assigning privileges to roles and assigning roles to users or groups. This method makes sense in a traditional hierarchical environment where there are clear lines of authority and responsibility around a relatively few number of different job types. A simple example is with employee records: the HR director role can view and edit all employee records, the manager role can view employee records for those they manage, and employees can only view their records.

The authorization process revolves around the following constructs:

• Secured Resource: A resource to which access is restricted. Indices, aliases, documents, fields, users, and the Elasticsearch cluster itself are all examples of secured objects.

• Privilege: A named group of one or more actions that a user may execute against a secured resource. Each secured resource has its own sets of available privileges. For example, read is an index privilege that represents all actions that enable reading the indexed/stored data.

• Permissions: A set of one or more privileges against a secured resource. Permissions can easily be described in words, here are few examples:

  • read privilege on the products index
  • manage privilege on the cluster
  • run_as privilege on john user
  • read privilege on documents that match query X
  • read privilege on credit_card field

• Role: A named set of permissions

• User: The authenticated user.

• Group: One or more groups to which a user belongs.

A role has a unique name and identifies a set of permissions that translate to privileges on resources. You can associate a user or group with an arbitrary number of roles. When you map roles to groups, the roles of a user in that group are the combination of the roles assigned to that group and the roles assigned to that user. Likewise, the total set of permissions that a user has is defined by the union of the permissions in all its roles.

RBAC is good, but has some limitations:

• The number of roles would balloon as an organization grew and as the number of kinds of data grew, making their management unwieldy
• Keeping roles mutually exclusive and collectively exhaustive (MECE) is hard, meaning it'd be possible to grant someone a number of contradictory roles that could result in a leak of data or other unintended behaviors
• Roles are meant to be generic and applicable to many people: they don't take
• user-specific information into account

An example of the last point is with health records: to view a person's private health information, a number of conditions must be met to include a recent HIPAA training certificate. Since everyone can take the training on different dates, no single role can take into account a person's training status. Training status is an attribute of the user.

Attribute-based access control (ABAC)

Attribute-based access control depends on attributes assigned to users, things, and actions, and a policy to make decisions based on them. For a user, attributes could include projects they work on, team memberships, certifications, years of service, and physical location. For a thing (i.e. resource), attributes could be sensitivity level, PII status, time-to-live (TTL), or physical location.

A real world control policy that is easier to model in ABAC is printing information in a secured environment: you can only print (action) from a specific printer (resource) if you are allowed to print things (action attribute + user attribute), that printer is near your workspace (resource attribute + user attribute), and your security training is up to date (contextual + information: current date + user attribute). In RBAC, you'd need a printing + role, a role for each printer (how many thousands in a big org?), need to update printing role membership everyday as users slipped out of training compliance, and update the membership in the printers' roles each day as people joined, left, and moved throughout the organization.

Resources

1. User authorization - https://www.elastic.co/guide/en/elasticsearch/reference/7.4/authorization.html#authorization
2. Document-level attribute-based access control with X-Pack 6.1 - https://www.elastic.co/blog/attribute-based-access-control-with-xpack