Skip to main content
Skip table of contents

Defining Policies & Rules

In TrustBuilder, Policies and Rules control access is based on user attributes and context. A Policy contains multiple Rules, and a combination algorithm defines how these rules are evaluated to grant or deny access.

TrustBuilder uses the XACML standard (eXtensible Access Control Markup Language) for defining and enforcing access control in a consistent, structured way..

TrustBuilder uses PBAC (Policy-Based Access Control), an extension of ABAC (Attribute-Based Access Control). Unlike role-based models, PBAC evaluates dynamic data like user attributes, context (time, device, etc.), and risk scores in real-time.

Create a policy

To create a policy from TrustBuilder Admin portal:

  1. Navigate to Access Management > Policies.

  2. Click on + Add Policy.

  3. Enter a name for your policy (without spaces) and a description.

    name-policy.gif
  4. Add one or more rules.
    (info) Rules are evaluated in order: the first rule is checked first, then the second, and so on.

    • If the rule already exists: drag and drop it under the policy

      drag-drop-rule.gif
    • If the rule does not yet exist, click on + Create new rule (see Create a rule).

  5. Choose a combination algorithm (see Combination):

    Policy-Combinaison.png
  6. Click on Save.

Create a policy using JSON view:
  1. Navigate to Access Management > Policies.

  2. Click on + Add Policy on the top-right corner.

  3. Click on the tree lines icon to switch to JSON view.

    Policy-JSONview.png
  4. Enter the policy attribute values:

    JSON
    {
      "name": "policy-name",
      "description": "Optional description",
      "rules": ["rule1", "rule2"],
      "combination": "DENY_OVERRIDES"
    }
  5. Click on Save.

Policy Attributes

Name

Unique identifier for the policy

String (in lowercase without space)

Description

Short explanation of the policy

String

Rules

List of rules assigned to the policy

Array of rule names

CODE
"rules": ["rule_name01","rule_name02","rule_name03","rule_name04"]

Combination

How rules are evaluated together to make the policy decision

No combination

If a policy has one rule, no need to apply an algorithm. The rule alone determines the decision.

DENY_OVERRIDES

Access is denied unless all rules permit. One deny overrides permit.

DENY_UNLESS_PERMIT

Access is denied unless at least one rule permits.

Policy example

Secure admin access

CODE
{
    "name": "secure-admin-access",
    "description": "Requires MFA and admin role for access",
    "rules": ["require_authent_aal1","only-admins","specific_userid"],
    "combination": "DENY_OVERRIDES"
}

Create a rule

CURRENT LIMITATIONS

The graphical rule editor has limitations. Use the JSON view for full capabilities.

To create a rule from TrustBuilder Admin portal:

  1. Navigate to Access Management > Rules.

  2. Click on + Add Rule.

  3. Click on the tree lines icon to switch to JSON view.

    Rule-JSON.png
  4. Enter the rule attribute values:

    • name → enter a name for your rule (without spaces).

    • description (optional) → enter a description of the rule.

    • effect"PERMIT" or "DENY" (see Effect).

    • condition → enter condition(s) (see Condition).

    • obligation (optional) → enter an obligation (see Obligation).

  5. Click on Save.

Rule Attributes

Name

Unique identifier for the rule

String (in lowercase without space)

Description

Short explanation of the rule (optional)

String

Effect

The access decision

"PERMIT" or "DENY"

Condition

A set of conditions that must be satisfied in order for the rule to be applied

Expressions in a rule condition are constructed as follows: { "<operator>": [ "<operand-1>", "<operand-2>", ... ] }

Operators in Conditions

equals

Is equal to the specified value

not_equals

Is not equal to the specified value

is_in

Is present in the list of specified values

not_in

Is not present in the list of specified values

has_value

  • Has a non-empty value (for single-valued operands)

  • Has at least one non-empty value (for multi-valued operands)

is_empty

(inverse of “Has a value”)

older_than

Is a timestamp and its value
Is longer ago than the duration stated in ISO 8601 format

not_older_than

Is a timestamp and its value

Is not longer ago than the duration stated in ISO 8601 format

elem_match

Is an array in which at least one element meets the embedded condition

not

Is the negated value of the nested expression

Operands in Conditions

Operands are values that define conditions. They can be:

  • Fixed values: strings, numbers, or dates (e.g., "2023-05-17").

  • Dynamic values: variables that reference session or user attributes.

    • Example: $session.user_id refers to the logged-in user's ID.

    • Attributes are accessed using a dot . (e.g., $session.persona.name retrieves the active persona's name).

Operand

Description

$session.user_id

uuid of the user of the current session

$session.started_at

The start data & time of the session identified with session_id

$session.persona.name

The name of the user's active persona in the current session.

$session.persona.id

The id of the user's active persona in the current session.

$session.persona.scope

The scope of the user's active persona in the current session.

$session.persona.is_preferred

The is_preferred value of the user's active persona in the current session.

$session.persona.entitlements

The entitlements of the user's active persona in the current session.

$session.persona.email

The email of the user's active persona in the current session.

$session.persona.valid_from

The valid_from value of the user's active persona in the current session.

$session.persona.valid_till

The valid_till value of the user's active persona in the current session.

$session.persona.status.current

The current status of the user's active persona in the current session.

$session.authentications

The list of the latest values of the acr and last_supplied_at of all types of authentications done by the user during this session. You can refer to those values by ~acr and ~last_supplied_at

$session.persona.attributes

The attributes of the user's active persona in the current session.

$session.persona.persona_definition_id

The persona_definition_id of the user's active persona in the current session.

$session.persona.attributes.category.name

The custom attribute category and the custom attribute name of the user's active persona in the current session.

$session.user.attributes.category.name

The custom attribute category and the custom attribute name of the user in the current session.

Combining Conditions

Use all-of (AND) or any-of (OR) to combine multiple conditions:

  • all-of → act as AND = all conditions must be met.

  • any-of → act as OR = at least one condition must be met.

Obligation

Additional actions required before granting access (optional)

requires_acr

The user must authenticate with a given assurance level(s) e.g requires_acr: [ "AAL3" ]

requires_persona

The user must switch to the given persona requires_persona: [ "doctor" ]

Authentication rule in policy

For a policy to work, it must include at least one rule that allows authentication.
Without authentication, the system cannot identify the user and therefore cannot evaluate conditions based on user attributes, persona, or session context.

A typical authentication rule checks whether the user has authenticated with a given assurance level (e.g., AAL1) and enforces this requirement as an obligation:

JSON
{
  "name": "require_authent_aal1",
  "effect": "PERMIT",
  "description": "Simple authentication with one factor",
  "condition": {
    "elem_match": [
      "$session.authentications",
      {
        "equals": [
          "~acr",
          "AAL1"
        ]
      }
    ]
  },
  "obligation": {
    "requires_acr": [
      "AAL1"
    ]
  }
}
  • The condition checks whether the session includes an authentication with AAL1 level.

  • The obligation ensures the user must authenticate using AAL1.

Match the ACR in the Access Flow

This rule only works if the Access Flow offers at least one authentication method that is mapped to the same ACR value (e.g., AAL1).

Exemple: A password-only login method should have an OIDC Context = AAL1 in the Access flow.

If no method in the Access Flow matches the required ACR, the policy will always deny access.

More information

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.