Role Based Access Control

Overview

In grafeo all CRUD operations are controlled by role-based access control. This controls what operations a subject (usually a user) is allowed to perform and what data a subject can access. Every data point stored in the system is owned by an organization. A permission is a triplet of (Subject, Organization, Function), i.e. one permission defines that a subject is allowed to perform an operation (function) for an organization. For example, if a subject is granted a read function for a specific organization the subject has access to the organization's data. Similarly, a create function could be granted to a subject for an organization in order to allow one subject to add data on behalf of the organization.

An access controller implementation is responsible for resolving subjects, organizations and permissions and to verify access to data and operations. Grafeo provides a simple reference implementation of an access controller based on a properties file as specified below, but it should be quite simple to replace that implementation if necessary.

Goals

• Have a simple implementation of subjects, organizations and permissions usable for testing role-based access control in the Object-Fact-Model.
• Implementation-independent access control checks:
  • Don't bind access control checks to a specific access controller implementation.
  • It should be easy to replace access controller implementation, e.g. with a LDAP implementation.

Properties-based Access Controller

• Define subjects, organizations and permissions in a properties file.
• Define subject groups, organization groups and function groups in properties file in order to allow inheritance. This simplifies the definition of permissions by granting access to groups where group members will inherit the granted permissions.
• In order to identify a user a specific HTTP header needs to be sent in a request containing the user's ID:
  • Header: Grafeo-User-ID
  • Value: user ID (numeric value)
  • Note: This is not a security feature, it's meant to simplify testing and will be removed in the future.
• Properties file:
  • The properties file is re-read in regular intervals such that changes can be made to the file without reloading the application.
  • IDs are numeric values (easier to define) and are mapped internally to application UUIDs.
  • Functions are identified by name and are defined in the application code.
  • When a key is defined multiple times in the properties file the last entry wins.
  • When defining group membership a group member can be another group in order to define an inheritance tree.
    • When a group member is not defined in the properties file it will just be skipped when traversing the tree.

Properties file

# Specify a function group with its members (comma-separated function or function group names).
# This entry must be present in order to define a function group.
# Single functions are defined implicitly by referring to them by name.
function.{name}.members = {name1},{name2},{name3}, ...

# Specify an organization with ID and name.
# This entry must be present in order to define an organization.
# If it is not present other entries referring to this organization will be skipped.
organization.{id}.name = {name}
 
# Specify an organization group by providing a group type and its members (comma-separated organization or organization group IDs).
# Both "name" and "type" entries must be present in order to define an organization group.
organization.{id}.name = {name}
organization.{id}.type = group
organization.{id}.members = {id1},{id2},{id3}, ...
 
# Specify a subject with ID and name.
# This entry must be present in order to define a subject.
# If it is not present other entries referring to this subject will be skipped.
subject.{id}.name = {name}
 
# Assign an affiliated organization to a subject.
subject.{id}.affiliation = {organizationID}
 
# Specify a subject group by providing a group type and its members (comma-separated subject or subject group IDs).
# Both "name" and "type" entries must be present in order to define a subject group.
subject.{id}.name = {name}
subject.{id}.type = group
subject.{id}.members = {id1},{id2},{id3}, ...
 
# Specify permissions for a subject by defining the functions the subject is allowed to perform for a specific organization.
# Permissions can both be defined on subjects / subject groups and organizations / organization groups.
# If subject is a group all group members will inherit the permissions assigned to the subject group.
# If organization is a group a subject will have access to all members of the organization group.
# Functions can either be a single function or a function group. When it is a group the subject will have access to all functions in the group.
subject.{subjectID}.permission.{organizationID} = {functionName1},{functionName2},{functionName3}, ...