Policy
The Volt4 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 Volt4 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 Volt4 integrates with SSI, see the Verifiable Credentials, Decentralized Identifiers (DIDs) and DID Registry pages.
Implementation
The Volt4 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 Volt4 infrastructure.
Within the Volt4 core there are implementations of Policy Information Points (PIPs) for subject, resource and environment.
Hierarchy
The policy engine supports the hierarchical nature of the Volt4 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 Volt4 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 Volt4 first boots. This contains the general rules pertaining to Volt4 ownership, resource ownership and so on, and this is persisted in the Volt4 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 Volt4 owner to perform any action, irrespective of the target resource:
{ "id": "volt-owner", "ruleCombiningAlgorithm": "first-applicable", "rules": [ { "description": "permit **Volt4** 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": ".*" } ] } ] } ] }}For more information see the policy definition page.