Policy Definitions & Assignments

Policy definitions and assignments are the two building blocks of Unified Security:

Policy definition (rules and value sources)
  + assignment (actor and assignment-owned values)
  = effective policy

A policy definition describes reusable security behavior for one connection. An assignment activates that definition for an actor and may supply values owned by assignments.

Policy definitions

A definition can contain CLS, SLS, RLS, or a supported combination. It has no effect until an assignment makes it applicable to an actor.

Persisted RLS declares each parameter once at definition scope:

{
  "name": "Tenant data access",
  "connectionId": "conn_123",
  "rlsConfig": {
    "parameters": {
      "tenant_id": {
        "source": "ASSIGNMENT",
        "missing": "NO_ROWS"
      },
      "record_status": {
        "source": "FIXED",
        "value": "active"
      }
    },
    "rules": [
      {
        "name": "Tenant isolation",
        "matcher": {
          "type": "ALL_TABLES_WITH_COLUMN",
          "column": "tenant_id"
        },
        "expression": "tenant_id = {{ tenant_id }} AND status = {{ record_status }}",
        "enabled": true
      }
    ]
  }
}

The definition answers:

• which entities each rule matches
• which row-filter expression it applies
• who owns each parameter value
• what happens when a dynamic value is missing

Assignments

An assignment binds one definition to one actor scope:

{
  "definitionId": "usd_123",
  "scopeType": "TENANT",
  "tenantId": "tenant_123",
  "params": {
    "tenant_id": "acme"
  }
}

This turns the definition on for tenant_123 and supplies the tenant_id value for that customer.

One actor can have at most one assignment per definition. To change what a customer receives, edit their existing assignment rather than adding a second.

Assignment scopes

Any of these makes the definition apply to the actor it names. All tenants is optional: use it when a policy should reach every customer, and skip it when only some customers should receive it.

When several assignments apply

A viewer can be covered by more than one assignment at once, and each policy type resolves that overlap in its own way. Connection security merges parameter values, schema security narrows within the inherited boundary, and row-level security takes the most specific value for each parameter.

For the row-level rules, see How Row-Level Security Works.

Configure and verify

In the Semaphor console:

1. Open the project's Security page.
2. Create or edit a policy definition.
3. Configure its rules and parameters.
4. Create assignments for the actors that should receive the policy.
5. Use Security preview to check representative tenants, tenant users, and organization users before anyone opens a dashboard.

If you are provisioning through the API, validate each candidate before you write it. See Automate with the API.

Next steps

• How Row-Level Security Works
• Set Up Row-Level Security
• Preview and Troubleshoot
• Automate with the API
• Token Integration