Composum Blog

various aspects of the Composum world
  1. Composum
  2. Blog
  3. Nodes
  4. Restrictions

Nodes Restrictions

In order to make the use of the Composum Nodes tools usable in different environments and still ensure security against unintended or unauthorized manipulation in the repository, individual features or even complete modules of the Nodes console can be restricted or completely disabled.

Ralf Wunsch
05.01.2022

All functions of the various nodes tools (browser, user manager, package manager) can be restricted via declared rules. These rules are configured via OSGi and can thus be varied for different systems depending on the runmode. Individual features can be disabled (none), protected against modifications (read) or even explicitly and completely permitted (write) in deviation from the general setting via these explicit, functional service restrictions using the associated key.

Key (Feature)

Purpose

core/commons/permissions

retrieval of permissions (ACLs) for the logged-in user; read only

core/commons/repository

retrieval of system parameters (property, node, mixin types); read only

core/commons/restrictions

API for querying the declared restrictions (read) or switching of the temporary default rules for the logged-in user (write)

core/commons/translation

retrieval of the translations for the currently used language; read only

core/job/execution

API for job control, querying the job status (read) or manipulating job execution and starting new jobs (write)

core/setup/execution

applying of ACLs (permissions) by executing appropriate setup scripts (write); write only

nodes/components/operations

component manipulation, e.g. create and remove component overlays (write); write only

nodes/components/scenes

retrieval (read) and create (write) scenes for testing components

nodes/packages/manager

display (read) and management (write) of installed content packages via the Nodes Package Manager

nodes/repository/nodetypes

retrieval of the defined node types as configuration file (read); read only

nodes/repository/permissions

retrieval (read) and manipulation (write) of the ACLs at the nodes of the repository

nodes/repository/properties

retrieval (read) and manipulation (write) of the properties of the nodes of the repository

nodes/repository/resources

retrieval (read) and manipulation (write) of the resources (JCR nodes or provided via provider) of the repository

nodes/repository/source

display and download in the source view of the browser (read); read only

nodes/repository/versions

retrieval (read) and manipulation (write) of the versions of the versionable nodes of the repository.

nodes/users/manager

display (read) and management (write) of users (system, service, regular users) via the Nodes User Manager

nodes/users/profile

retrieval of a user's profile data (read); read only

system/cpm/clientlibs

analysis and retrieval of Composum clientlibs (read); read only

system/service/graph

analysis and graphical representation of services and their dependencies (read); read only

system/osgi/bundles

display of OSGi bundles and their status (read); read only

system/runtime/files

display of files in the working directory of the sling instance (read), the path pattern of the allowed files can be further restricted via regular expressions; read only

system/runtime/threads

analysis of the running threads (read); read only

system/sling/adapters

proxy of the Sling Webconsole to analyze the available adapters (read); read only

system/sling/requests

proxy of the Sling Webconsole to analyze the last Sling requests (read); read only

system/sling/resolver

proxy of the Sling Webconsole to analyze the Sling Resolver configuration (read); read only.

system/sling/servlets

Sling Webconsole proxy to analyze the Sling servlet resolver (read); read only.

system/sling/jobs

proxy of the Sling Webconsole to analyze the Sling jobs (read); read only.

system/webconsole

iFrame of the Sling Webconsole (only if Webconsole is available)

For each of the features (keys) the general restriction - none / read / write - can be defined. For individual users or user groups, additional deviating rules can be defined. Individual features also allow additional patterns to further restrict access in detail.

Examples

The configuration of the service restrictions is done via matching OSGi configuration files to the implementing service - com.composum.sling.core.service.impl.ServiceRestrictionsImpl - in the respective preferred format. Below are a few examples in JSON format (com.composum.sling.core.service.impl.ServiceRestrictionsImpl.cfg.json):

  1. Removable Restriction

    { "enabled": true, "defaultPermission": "read", "userOption": "write", "restrictions": [ "system/service/graph=none" ] }

    Configures 'read' as the default functional constraint for all services and allows the user to temporarily extend it to 'write' if they see fit. However, the service dependency visualization feature is completely disabled.

    This configuration is a kind of 'self-protection' against accidental changes.

    The 'enabled' property allows the service restrictions itself. An 'enabled=false' disables the functional restrictions!

  2. No Manipulation allowed and File Access Limited to log files

    { "enabled": true, "defaultPermission": "read", "userOption": "read,write:admin", "restrictions": [ "system/runtime/files=read:^/((sling|launcher)(/logs(/[^.]+\\.log(.[0-9-]+)?)?)?)?$" ] }

    The default 'read' restriction can only be temporarily disabled by the 'admin' user. Without the additional rule for the 'admin' user, no user could temporarily disable the 'read' restriction.

    For the retrieval (display or download) of the files of the working directory, a restriction to log files defined by a corresponding regular expression of the allowed file paths applies.

  3. Productive Use

    The following example only allows read-only browsing of the repository without ACL access. In addition, all 'system' features are prohibited except for access to the log files. Such a configuration could possibly allow the use of the nodes tools in a production system.

    { "enabled": true, "defaultPermission": "read", "userOption": "read", "restrictions": [ "core/job=none", "core/setup=none", "nodes/components=none", "nodes/packages=none", "nodes/users=none", "nodes/repository/permissions=none", "system=none", "system/runtime/files=read:^/((sling|launcher)(/logs(/[^.]+\\.log(.[0-9-]+)?)?)?)?$" ] }

    If the installations / updates are done via the package manager, then this feature and the used 'core' features must be explicitly allowed (write), if the default setting is reduced to 'read', otherwise the installation of a package and thus possibly also the change of this configuration is not (anymore) possible:

    { "enabled": true, "defaultPermission": "read", "restrictions": [ "core/job=write", "core/setup=write", "nodes/packages/manager=write" ] }

The functional service restrictions supplement the restrictions defined via ACLs in the repository. The ACLs continue to apply without restriction and in addition. They are not overridden in any case by any administrative permissions of the nodes tools. The functional restrictions of the Composum Nodes via ACLs on the Nodes components are also still possible.

Status display and status adjustment

The currently set default restriction is displayed in the Nodes Console in the navigation bar on the right-hand side next to the current user ID, provided that the tool currently used in the Console supports service restrictions.

The 'shield' symbol illustrates the 'read' restriction, a 'wrench' the 'write' status. If a different temporary user option is possible, the default restriction can be switched by clicking on the symbol. A colored background is used if the current status is a temporary user option. It is also possible to temporarily downgrade a configured 'write' restriction (everything allowed) as user to 'read', e.g. to exclude accidental changes.

powered by Composum Pages @ Composum Cloud