Fine-grained user permissions in OSH

The latest version of OpenSensorHub now gives fine-grained control over user permissions and other security options.

In addition to better support for HTTPS (SSL) and several authentication methods (HTTP Basic, HTTP Digest, X509 Certificate, OAuth) through simple configuration in the web admin interface, a hierarchy of permissions can now be defined by each OSH module needing some kind of access control. These permissions can then be assigned to users and roles using the security API. 

For instance, below is an extract of the permission tree that is defined by each instance of the Sensor Observation Service (SOS) module:

- SOS
  - get
    - caps (capabilities)
      - offering1 
      - offering2 ...
    - sensor (sensorML description)
      - offering1
      - offering2 ...
    - obs (observations)
      - offering1
      - offering2 ...
    - foi (features of interest) 
  - insert
    - sensor
    - obs
      - offering1
      - offering2 ...
  - update
    - ...
  - delete
    - ...

Permissions can be granted or denied at each level of the tree for a given user. For instance, the administrator would have access to everything:

Allow sos[*]/*

But a regular user may only be granted read  access to the service, with the following permission statement:

Allow sos[*]/get/*

A user or device that produces data could be granted write access but only to the offering that it produces data for:

Allow sos[*]/update/sensor/offering[urn:offering01]
Allow sos[*]/insert/obs/offering[urn:offering01]

It’s also possible to deny permissions, which takes precedence over allowed ones:

Allow sos[*]/*
Deny sos[*]/delete/*

A default security realm implementation is provided and allows creating users, roles, and assigning permissions directly from the web admin interface. When using this module, everything is kept in-memory and gets saved in the main OSH configuration file so it’s very easy to edit. Adding/removing users, roles and assigning permissions can also be done super easily in the Web Admin UI, as shown on the screenshot below:

However, administrators of networks that can include a large number of OSH nodes will usually need to manage authentication and authorization in a centralized/federated manner. So, in addition to this simple config file approach to authorization, the security API is flexible enough to allow authentication, identity retrieval and authorization using external services (examples include authenticating users using an OAuth identity provider, fetching user, role and/or permission information from a remote directory such as LDAP, or controlling access using a XACML based Policy Decision Point – PDP). Such functionality doesn’t come out-of-the-box in OSH yet though: The security API provides java interfaces where this functionality can be plugged-in at runtime but a separate software module must be implemented to add support for each of these protocols.