Policy

The tdx Volt security policy is based on XACML.

XACML is an attribute-based policy language. Policy rules are defined in terms of the attributes, and in the case of the tdx Volt the 4 main attribute types are subject (the identity), resource, action and environment.

This document won’t go into full details of how XACML works, please refer to the XACML standard.

SSI integration

Self-sovereign identity (SSI) is a method of managing digital identities in a way that is independent of any central authority. For more information, see SSI.

This provides a powerful and flexible way to define policy rules that are based on the identity of the subject, and the issuers of the credentials that the subject holds.

For example, a policy rule could be defined that permits a subject to perform an action on a resource if they hold a credential that was issued by a specific issuer, such as a government department.

For more information on how the tdx Volt integrates with SSI, see the Verifiable Credentials, Decentralized Identifiers (DIDs) and DID Registry pages.

Implementation

The tdx Volt policy engine is a stand-alone library that implements large parts of the XACML standard, as well as the multiple decision and hierarchical resource profiles, with no hardwiring to the tdx Volt infrastructure.

Within the tdx Volt core there are implementations of Policy Information Points (PIPs) for subject, resource and environment.

Hierarchy

The policy engine supports the hierarchical nature of the tdx Volt resource tree via the multiple decision and hierarchical resource profiles.

This allows rules that are applied to a parent resource to be inherited by its descendants, and greatly simplifies the policy rules required to protect the Volt.

Persistence

The tdx Volt uses JSON to persist policies rather than XML, but the underlying semantics are the same.

Note that a ‘root’ policy set is created when the tdx Volt first boots. This contains the general rules pertaining to tdx Volt ownership, resource ownership and so on, and this is persisted in the tdx Volt database.

Resource sharing rules that are added as a result of calls to SaveAccess are dynamically included in the policy at runtime.

Examples

The example below shows a policy that permits the tdx Volt owner to perform any action, irrespective of the target resource:

{
"id": "volt-owner",
"ruleCombiningAlgorithm": "first-applicable",
"rules": [
{
"description": "permit **tdx Volt** owner to perform any action",
"effect": "permit"
}
],
"target": {
"allOf": [
{
"anyOf": [
{
"allOf": [
{
"attributeId": "tdx:action",
"category": "action",
"dataType": "string",
"functionId": "string-regexp-match",
"value": ".*"
},
{
"attributeId": "tdx:identityId",
"category": "subject",
"dataType": "string",
"functionId": "string-equal",
"value": "449a3385-f380-41f7-bd0a-e60caaa403cb"
}
]
}
]
}
]
}
}

This example shows a rule that permits subjects (identities) to perform any action on any resource they own. It makes use of a ‘condition’ to dynamically interrogate the resource PIP to establish the owning identity. It then compares this to the currently authenticated identity and if the two match, it permits the subject to perform any action:

{
"id": "resource-owner",
"ruleCombiningAlgorithm": "first-applicable",
"rules": [
{
"condition": {
"args": [
{
"attributeId": "tdx:identityId",
"category": "subject",
"dataType": "string",
"typeName": "AttributeDesignator"
},
{
"attributeId": "tdx:resourceOwner",
"category": "resource",
"dataType": "string",
"typeName": "AttributeDesignator"
}
],
"functionId": "string-equal",
"typeName": "Apply"
},
"description": "permit resource owner create/delete/read/write access",
"effect": "permit"
}
],
"target": {
"allOf": [
{
"anyOf": [
{
"allOf": [
{
"attributeId": "tdx:action",
"category": "action",
"dataType": "string",
"functionId": "string-regexp-match",
"value": ".*"
}
]
}
]
}
]
}
}