Purpose

The main purpose of user-level access control is to allow the realm administrator to define which users have access to which Qeo data Topics.

Prerequisites

There are prerequisites on two levels:

  • Basic security configuration: The Realm Administrator has set up the Realm
  • Policies: The default Qeo security policy allows every user added to the realm read and write access to every Qeo topic. If the Realm Administrator wants to deviate from this, he needs access to the Security Management Server (SMS) such he can edit the policy.

To allow Qeo-enabled devices to apply the realm policy, at least one Qeo device in the Realm requires access to the SMS to pull the latest policy file. Once pulled, this access is no longer required until the need for a new update arises.

Architecture

On the Security Management Server (SMS)

The SMS manages and stores the Qeo security policy per Realm, and offers the Administrator the possibility to edit policy rules per user. The Realm security policy is actually a concatenation of all security policies of all users.

On the Qeo-Enabled Device

The realm policy is pushed toward the Policy Enforcement Points (PEPs), which store it and enforce the configured rules.

Actors

The following actors take part:

  • Qeo Realm Administrator: specify the needed policy rules.
  • Security Management Server: store and provide the policy file to qeo-enabled devices.
  • Qeo-enabled devices: the Policy Enforcement Point (PEP) enforces the policy rules.

Concepts

Policy (File)

The Qeo Policy is a set of white list rules. These rules define which topics a User in the Realm can access. If a topic is not mentioned in a user's rules, the user has no access whatsoever to that topic. There are two kinds of rules: coarse-grained and fine-grained.

  • Coarse-grained rules grant a user wholesale access to all data on a topic for either reading, writing, or both.
  • Fine-grained rules further restrict a user's access to a given topic. With these rules, you can express that a user may only see data on the topic that was published by certain users, or that the data that a user publishes on the topic can only be seen by certain other users.

Within the same policy, for a single topic,

  • you can define a coarse-grained rule for some users and a fine-grained rule for other users
  • you cannot grant a single user fine-grained read rights and coarse-grained write rights or vice versa.

For information on the policy file syntax and interpretation rules, refer to How to Define a Policy.

Obtaining the Policy and redistribution

When a PEP starts up, it checks whether there is a policy stored already on the device. If this is not the case yet (e.g. the PEP starts up for the first time or the policy is removed on the device), the policy is fetched from the SMS, validated, enforced and published on the Qeo topic org::qeo::system::policy in the secured Qeo realm. This way of working assures that the other PEP's in the realm are provided with the latest policy just fetched by the former PEP. Upon receiving a new policy, the PEP validates, enforces and stores it on the device.

Policy Updates

Whenever a policy is updated on the SMS (i.e due to a user being added, or existing policy rules being modified) , every PEP in the Qeo realm needs to obtain and enforce this updated policy to become effective.

Fetching of an updated policy file from the SMS can be done in multiple ways:

  • Android:
    1. The Qeo Management Application for Android (i.e. an Android Service) checks every 2 minutes if it still has the latest policy. If this is not the case, it is fetched from the SMS and redistributed within the realm.
  • Native C / Linux:
    1. Remove the policy file on one of the devices in the Realm and restart one of the apps on the device.
      The policy file is stored in the ~/.qeo directory. and has a name similar to 2b_policy.mime (with 2b being the realm ID).

      or
       
    2. Launch the Qeo safeguard daemon, which will check every 2 minutes if the latest policy is available. If this is not the case, it is fetched from the SMS and redistributed within the realm.
      The daemon can be found in $QEO_HOME/c/bin/<ARCH>/qeo-safeguard-d. E.g. use the following command to launch the daemon for i686-linux:

      LD_LIBRARY_PATH=$QEO_HOME/c/lib/i686-linux $QEO_HOME/c/bin/i686-linux/qeo-safeguard-d

IMPORTANT

Icon

Policy updates are enforced within 2 minutes, provided that the Qeo Management application or Qeo safeguard daemon can contact the SMS.

Notes

Please take note of the following:

  • A Qeo user (as known on the SMS) has the same access rights regardless of the devices he/she uses.