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:
Navigate to Access Management > Policies.
Click on + Add Policy.
Enter a name for your policy (without spaces) and a description.
Add one or more rules.
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
If the rule does not yet exist, click on + Create new rule (see Create a rule).
Choose a combination algorithm (see Combination):
Click on Save.
Policy Attributes | ||||||
---|---|---|---|---|---|---|
NameUnique identifier for the policy String (in lowercase without space) | ||||||
DescriptionShort explanation of the policy String | ||||||
RulesList of rules assigned to the policy Array of rule names
CODE
| ||||||
CombinationHow rules are evaluated together to make the policy decision
|
Policy example
Secure admin access |
CODE
|
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:
Navigate to Access Management > Rules.
Click on + Add Rule.
Click on the tree lines icon to switch to JSON view.
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).
Click on Save.
Rule Attributes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NameUnique identifier for the rule String (in lowercase without space) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
DescriptionShort explanation of the rule (optional) String | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
EffectThe access decision
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
ConditionA set of conditions that must be satisfied in order for the rule to be applied Expressions in a rule condition are constructed as follows: Operators in Conditions
Operands in Conditions Operands are values that define conditions. They can be:
Combining Conditions Use
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
ObligationAdditional actions required before granting access (optional)
|
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:
{
"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.