Various permission and security features ensure that Vault users only have access to the functions, documents, and object records that are appropriate for their roles and responsibilities. These include features such as security profiles that control access to certain functions, document roles that control access to view and perform actions on documents, and object record roles that control access to view and perform actions on specific object data records.
All permissions and access control configuration in Vault also apply to developer tools such as Vault API and Vault Java SDK. When developing integrations, it is important to understand how to interact with Vault security to ensure your integration has the correct permissions to execute necessary business processes.
Child object security replicates sharing settings from a parent object to a child object. In the Vault UI, this configuration option is labelled Replicate sharing settings from parent object. Learn more about child object security in Vault Help.
To determine if a record is secured with child object security, developers can view the replicate_sharing_from_parent Boolean attribute on the Object MDL component, where true indicates child object security is enabled.
When developing with objects utilizing child object security, access control extends to access with developer tools such as the Vault Java SDK and Vault API. For example:
When child object security is enabled, Vault deletes Custom Sharing Rules and Matching Sharing rules. Developers should evaluate existing custom solutions before enabling this setting.
To enable child object security, developers can use Vault API’s Execute MDL Script endpoint to set the replicate_sharing_from_parent Boolean attribute to true. You can also execute MDL commands with Vault Toolbox.
For example, the following MDL enables child object security on the child_object__c object:
ALTER Object child_object__c (
MODIFY Field parent_object_reference_field__c(
replicate_sharing_from_parent(true)
)
);
In addition to retrieving the replicate_sharing_from_parent Boolean attribute on the Object MDL component, you can also check this attribute with Vault Java SDK.
Because child object security is configured on the parent object, you can use the Vault Java SDK ObjectParentReferenceFieldMetadata interface to determine if a child record is secured with child object security. This interface provides the #isReplicateSharingFromParent() method, which returns true if the parent has child object security enabled, otherwise false. View this method in the Javadocs.
For example:
// Initialize service
ObjectMetadataService objectMetadataService = ServiceLocator.locate(ObjectMetadataService.class);
// Build the request object for retrieving campaign__c object metadata
ObjectMetadataRequest objectMetadataRequest = objectMetadataService.newObjectRequestBuilder()
.withObjectName("campaign__c")
.build();
// Retrieve campaign__c object metadata
ObjectMetadata campaignMetadata = objectMetadataService.getObject(objectMetadataRequest);
// Retrieve enablement status of child object security
boolean isChildSecurityEnabled = campaignMetadata.isReplicateSharingFromParent();
Security trees allow Admins to control access to object records based on a hierarchical structure, similar to a tree. Admins can assign application roles and records to security trees through nodes, which are object records created on the security tree. User application role access can cascade down through a hierarchy, while read access to object records can roll up through a hierarchy. Only objects with data_store=standard can be secured by a security tree. Learn more about Tree Security in Vault Help.
To develop with security trees, you must understand the Vault objects involved in configuration.
The following is an example of a Security Tree object retrieved through MDL:
Object security_tree__c (
label('Security Tree'),
object_class('securitytree'),
user_tree_assignment_object_name('user_assignment'),
single_user_tree_assignment(true),
user_reference_assignment()
);
securitytree for security tree objects. Only security tree objects can be of class securitytree. Learn more about object classes in Vault Help._c__sys namespace. For example, the full name of this object in the example MDL above is user_assignment_c__sys. This object allows you to assign a user to a node in a security tree with an assigned Application Role. This attribute can only be set on create. Learn more about the User Tree Assignment Object.false and users are not restricted to a single node assignment. Learn more about single node assignment in Vault Help.The following is an example of a custom object secured by a security tree retrieved through MDL:
Object my_custom_object__c (
label('My Custom Secured Object'),
security_tree_object('Object.security_tree__c'),
tree_assignment_object_name('user_tree_assignment')
);
securedrecordtreeassignment. If blank, this object is not secured by a security tree. Learn more about Secured Record Tree Assignment in Vault Help.As a Vault Admin, you can configure security trees in the Vault UI. Learn more about how to configure security trees in Vault Help.
As a developer, you can create, update, or delete a security tree with Vault API’s Execute MDL Script endpoint. You can also execute MDL commands with Vault Toolbox.
For example, the following request will create a security tree:
CREATE Object my_security_tree_mdl__c (
label('My Security Tree'),
label_plural('My Security Trees'),
active(true),
object_class('securitytree'),
user_tree_assignment_object_name('user_tree_assignment'),
audit(true),
in_menu(true)
);
Learn more about security tree-specific attributes in Developing with Tree Security. You can also learn more about Object component fields, such as audit and in_menu, in the Component Reference.
You can enable tree security on an object by setting a value for the security_tree_object and tree_assignment_object_name attributes with the Vault API’s Execute MDL Script endpoint. You can also execute MDL commands with Vault Toolbox.
For example, the following code enables tree security on the campaign__c custom object:
ALTER Object campaign__c (
security_tree_object('Object.security_tree__c'),
tree_assignment_object_name('user_tree_assignment')
);
Security tree nodes are Security Tree object records. Once you have created a Security Tree object (an object of class securitytree), you can create, update, and delete security tree nodes the same way you would create, update, or delete object records with Vault API or Vault Java SDK.
For example, the following request uses Vault API’s Create & Upsert Object Records endpoint to create a security tree node on the security_tree__c security tree:
curl -X POST -H "Authorization: {SESSION_ID}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
--data-raw '[
{
"name__v": "My New Security Tree Node",
"parent_node__sys": "V8S000000002001"
}
]' \
https://myvault.veevavault.com/api/v25.2/vobjects/security_tree__c
| Name | Description |
|---|---|
name__vrequired | The name of this new security tree node, visible to Admins in the Vault UI and to developers as the name__v value. |
parent_node__sysconditional | The ID of an existing node in this security tree to assign as the parent to this new node. If omitted, creates a root node. Each security tree can contain only one root node. |
{
"responseStatus": "SUCCESS",
"data": [
{
"responseStatus": "SUCCESS",
"data": {
"id": "V8S000000003002",
"url": "/api/v25.2/vobjects/security_tree__c/V8S000000003002"
}
}
]
}
Security trees are fully queryable with VQL, including objects in the _c__sys namespace.
For example, the following query retrieves all nodes associated with the security_tree__c security tree:
SELECT id, name__v, parent_node__sys
FROM security_tree__c
{
"responseStatus": "SUCCESS",
"responseDetails": {
"pagesize": 1000,
"pageoffset": 0,
"size": 3,
"total": 3
},
"data": [
{
"id": "V8S000000002002",
"name__v": "Security Tree Node",
"parent_node__sys": "V8S000000003001"
},
{
"id": "V8S000000003001",
"name__v": "Security Tree Root Node",
"parent_node__sys": null
}
]
}