RULE Syntax

Write Your Broker’s Access Policy

Every broker operation—creating users, deploying Actions, publishing to topics—passes through Rules before it executes. This page is the complete syntax reference for writing those rules: the conditions you can check, the scopes you can target, and the patterns that tie them together.

Like writing house rules on a whiteboard. Each rule says “IF you are on the approved list, THEN you may enter the room—ELSE the door stays locked.” LoT rule syntax works the same way: you name the rule, pick the door (scope), and write the condition.

When You Need This Reference

Scenario	You’ll use
Restricting who can create or delete users	User Management scopes
Controlling who deploys Actions, Models, or Routes	Entity Management scopes
Locking down MQTT topic access per user or role	Publish / Subscribe scopes with `TO TOPIC`
Protecting `$SYS` command topics	System topic scopes
Building role-based access across departments	Permission tags with `USER HAS`

Deploying rules: In a LoT Notebook, just write the rule and run the cell—the extension handles the rest. For MQTT clients, use the -addRule broker command.

Rule Structure — the anatomy of every rule definition
Conditions — user identity checks, permission checks, and combining logic
Operation Scopes — every scope category (user, entity, asset, system, log)
Topic Access Rules — controlling Publish/Subscribe on standard and $SYS topics
Permission Tags — standard tags and how to use them
Priority and Evaluation — how the broker picks which rule wins
Complete Examples — production-ready rule sets for common scenarios

Rule Structure

Every rule follows this structure:

DEFINE RULE <RuleName> WITH PRIORITY <number> FOR <Scope> [TO TOPIC "<pattern>"]
    IF <condition> THEN
        ALLOW
    ELSE
        DENY

Component	Description
`RuleName`	Unique identifier for the rule
`PRIORITY`	Evaluation order (lower numbers = higher priority)
`Scope`	The operation type this rule controls
`TO TOPIC`	Optional topic pattern for Publish/Subscribe rules
`condition`	Logic that determines access (user checks, permissions)

Conditions

Rules evaluate conditions to decide whether to ALLOW or DENY an operation.

User Identity Checks

Check if the current user matches a specific username:

USER IS "root"
USER IS "admin"

Permission Checks

Check if the user has a specific permission tag:

USER HAS AllowedUserManagement
USER HAS AllowedSystemConfiguration
USER HAS AllowedAssetManipulation

Combining Conditions

Use OR and AND to create complex conditions:

IF USER HAS AllowedUserManagement OR USER IS "root" THEN
    ALLOW

IF USER HAS AllowedSystemConfiguration AND USER IS "admin" THEN
    ALLOW

Operation Scopes

Rules control different categories of operations. Each scope targets specific broker functionality.

User Management

Control who can manage broker users:

Scope	Controls
`UserManagementCreation`	Creating new users
`UserManagementRemove`	Deleting users
`UserManagementUpdate`	Modifying user parameters
`UserManagementPasswordChange`	Changing user passwords

This example allows users with the AllowedUserManagement permission or the root user to create new accounts:

DEFINE RULE AllowUserCreation WITH PRIORITY 1 FOR UserManagementCreation
    IF USER HAS AllowedUserManagement OR USER IS "root" THEN
        ALLOW
    ELSE
        DENY

Entity Management

Control who can create and manage LoT entities:

Scope	Controls
`ActionManagementCreation`	Creating Actions
`ActionManagementRemove`	Deleting Actions
`ActionManagementRun`	Manually running Actions
`ModelManagementCreation`	Creating Models
`ModelManagementRemove`	Deleting Models
`RouteManagementCreation`	Creating Routes
`RouteManagementRemove`	Deleting Routes
`RuleManagementCreation`	Creating Rules
`RuleManagementRemove`	Deleting Rules

This example restricts Action creation to administrators and the root user:

DEFINE RULE AllowActionAdd WITH PRIORITY 1 FOR ActionManagementCreation
    IF USER HAS AllowedSystemConfiguration OR USER IS "root" OR USER IS "admin" THEN
        ALLOW
    ELSE
        DENY

Asset Management

Control who can manage installed assets (plugins, extensions):

Scope	Controls
`AssetManagementCreation`	Installing assets
`AssetManagementRemove`	Uninstalling assets
`AssetManagementStart`	Starting assets
`AssetManagementStop`	Stopping assets
`AssetManagementPolicySet`	Setting asset policies

This example allows asset installation only for users with the appropriate permission:

DEFINE RULE AllowAssetInstall WITH PRIORITY 1 FOR AssetManagementCreation
    IF USER HAS AllowedAssetManipulation OR USER IS "root" THEN
        ALLOW
    ELSE
        DENY

System Operations

Control access to system-level operations:

Scope	Controls
`SystemConfiguration`	Changing broker configuration
`ShellCommand`	Executing shell commands
`CommandCall`	Calling broker commands

This example restricts configuration changes to authorized administrators:

DEFINE RULE AllowConfigurationChange WITH PRIORITY 1 FOR SystemConfiguration
    IF USER HAS AllowedSystemConfiguration OR USER IS "root" THEN
        ALLOW
    ELSE
        DENY

Log Management

Control who can manage log traces:

Scope	Controls
`LogManagementCreation`	Creating log traces
`LogManagementRemove`	Deleting log traces
`LogManagementUpdate`	Modifying log traces

This example allows log trace management for users with logging permissions:

DEFINE RULE AllowLogTraceCreation WITH PRIORITY 1 FOR LogManagementCreation
    IF USER HAS AllowedLogManagement OR USER IS "root" THEN
        ALLOW
    ELSE
        DENY

Topic Access Rules

Control who can publish to or subscribe from specific MQTT topics.

Standard Topics

Use Publish and Subscribe with TO TOPIC to control access:

DEFINE RULE AllowPublishTopic WITH PRIORITY 1 FOR Publish TO TOPIC "#"
    ALLOW

DEFINE RULE AllowSubscribeTopic WITH PRIORITY 1 FOR Subscribe TO TOPIC "#"
    ALLOW

System Topics ($SYS)

Use PublishSys and SubscribeSys for system topic access:

DEFINE RULE AllowSubscribeSysClient WITH PRIORITY 1 FOR SubscribeSys TO TOPIC "$SYS/#"
    IF USER IS "root" THEN
        ALLOW
    ELSE
        DENY

DEFINE RULE AllowPublishSysCommand WITH PRIORITY 1 FOR PublishSys TO TOPIC "$SYS/Coreflux/Command"
    IF USER HAS AllowedAssetManipulation OR USER HAS AllowedSystemConfiguration THEN
        ALLOW
    ELSE
        DENY

System topics ($SYS/#) contain sensitive broker information and command interfaces. Restrict access to administrative users only.

Permission Tags

Permission tags are assigned to users and checked with USER HAS. These are the standard permission tags:

Permission Tag	Grants Access To
`AllowedUserManagement`	User creation, removal, updates
`AllowedSystemConfiguration`	System config, rules, shell commands
`AllowedAssetManipulation`	Asset install, start, stop, policies
`AllowedLogManagement`	Log trace creation, removal, updates
`AllowedModelManagement`	Model creation and removal

You can define custom permission tags for your organization. Assign them to users through the broker’s user management system.

Priority and Evaluation

Rules are evaluated in priority order (lower number = higher priority). The first matching rule determines the outcome.

// This rule is evaluated first (priority 1)
DEFINE RULE DenyGuestUsers WITH PRIORITY 1 FOR ActionManagementCreation
    IF USER IS "guest" THEN
        DENY

// This rule is evaluated second (priority 2)
DEFINE RULE AllowAdminUsers WITH PRIORITY 2 FOR ActionManagementCreation
    IF USER IS "admin" THEN
        ALLOW

Use lower priority numbers for more specific rules (like denying specific users) and higher numbers for general allow/deny rules.

Structure layered access as specific deny rules first, then broader allow rules:

DEFINE RULE ProtectSysTopics WITH PRIORITY 10 FOR PublishSys
    IF USER IS "root" THEN
        ALLOW
    ELSE
        DENY

DEFINE RULE AllowDevicePublish WITH PRIORITY 50 FOR Publish TO TOPIC "sensors/#"
    IF USER HAS AllowedSensorPublish THEN
        ALLOW
    ELSE
        DENY

Practice	Guideline
Priority 1–20	Critical deny rules (system protection)
Priority 21–50	Specific allow rules (per-feature access)
Priority 51–100	General allow rules (broad access)
Condition style	Prefer `USER HAS <permission>` over `USER IS "<name>"` for maintainability

Complete Examples

Multi-User Environment
IoT Device Access
Department Isolation

A typical production setup with role-based access control:

// Only root can manage users
DEFINE RULE RestrictUserManagement WITH PRIORITY 1 FOR UserManagementCreation
    IF USER IS "root" THEN
        ALLOW
    ELSE
        DENY

// Admins and root can deploy Actions
DEFINE RULE AllowActionDeployment WITH PRIORITY 1 FOR ActionManagementCreation
    IF USER IS "root" OR USER IS "admin" THEN
        ALLOW
    ELSE
        DENY

// Users with permission can manage models
DEFINE RULE AllowModelManagement WITH PRIORITY 1 FOR ModelManagementCreation
    IF USER HAS AllowedModelManagement OR USER IS "admin" THEN
        ALLOW
    ELSE
        DENY

// Everyone can publish to non-system topics
DEFINE RULE OpenPublish WITH PRIORITY 1 FOR Publish TO TOPIC "#"
    ALLOW

// Restrict $SYS subscriptions to root
DEFINE RULE ProtectSysTopics WITH PRIORITY 1 FOR SubscribeSys TO TOPIC "$SYS/#"
    IF USER IS "root" THEN
        ALLOW
    ELSE
        DENY

Limit IoT devices to their own topic namespace:

// Devices can only publish to their own topics
DEFINE RULE DevicePublishRestriction WITH PRIORITY 1 FOR Publish TO TOPIC "devices/#"
    IF USER HAS DevicePermission THEN
        ALLOW
    ELSE
        DENY

// Devices cannot access command topics
DEFINE RULE DenyDeviceCommands WITH PRIORITY 1 FOR PublishSys TO TOPIC "$SYS/Coreflux/Command"
    IF USER HAS DevicePermission THEN
        DENY

// Devices can subscribe to their config topics
DEFINE RULE DeviceConfigSubscription WITH PRIORITY 1 FOR Subscribe TO TOPIC "config/devices/#"
    IF USER HAS DevicePermission THEN
        ALLOW
    ELSE
        DENY

Separate access by organizational department:

// Engineering team access
DEFINE RULE EngineeringPublish WITH PRIORITY 1 FOR Publish TO TOPIC "engineering/#"
    IF USER HAS EngineeringAccess THEN
        ALLOW
    ELSE
        DENY

// Operations team access
DEFINE RULE OperationsPublish WITH PRIORITY 1 FOR Publish TO TOPIC "operations/#"
    IF USER HAS OperationsAccess THEN
        ALLOW
    ELSE
        DENY

// Shared topics for cross-team communication
DEFINE RULE SharedTopicAccess WITH PRIORITY 1 FOR Publish TO TOPIC "shared/#"
    IF USER HAS EngineeringAccess OR USER HAS OperationsAccess THEN
        ALLOW
    ELSE
        DENY

Best Practices

Start with deny-by-default

Create restrictive rules first, then add specific allow rules for authorized users. This prevents accidental access.

Use permission tags over usernames

Check USER HAS <permission> rather than USER IS "<name>" when possible. This makes it easier to manage access as users change.

Protect $SYS topics

Always restrict access to $SYS/# topics. These contain broker commands and sensitive system information.

Document your rules

Use clear, descriptive rule names that explain their purpose. AllowAdminActionCreation is better than Rule1.

Quick Start

Developing and Managing Coreflux

Coreflux MQTT Broker

LoT Language

Product Updates

Write Your Broker’s Access Policy

When You Need This Reference

On This Page

Rule Structure

Conditions

User Identity Checks

Permission Checks

Combining Conditions

Operation Scopes

User Management

Entity Management

Asset Management

System Operations

Log Management

Topic Access Rules

Standard Topics

System Topics ($SYS)

Permission Tags

Priority and Evaluation

Complete Examples

Best Practices

Next Steps

Actions Guide

Models Guide

​Write Your Broker’s Access Policy

​When You Need This Reference

​On This Page

​Rule Structure

​Conditions

​User Identity Checks

​Permission Checks

​Combining Conditions

​Operation Scopes

​User Management

​Entity Management

​Asset Management

​System Operations

​Log Management

​Topic Access Rules

​Standard Topics

​System Topics ($SYS)

​Permission Tags

​Priority and Evaluation

​Complete Examples

​Best Practices

​Next Steps

Actions Guide

Models Guide

Write Your Broker’s Access Policy

When You Need This Reference

On This Page

Rule Structure

Conditions

User Identity Checks

Permission Checks

Combining Conditions

Operation Scopes

User Management

Entity Management

Asset Management

System Operations

Log Management

Topic Access Rules

Standard Topics

System Topics ($SYS)

Permission Tags

Priority and Evaluation

Complete Examples

Best Practices

Next Steps