Access control lists (ACLs) allow you to define fine-grained access to object instances and their properties directly in your data model.
ACLs are composed of access control definitions. These definitions take the following forms:
"type": <access target type>,
"target": <access target identifier>,
"allow": <access level>
These definitions are evaluated and applied to the specified targets at runtime.
By default, Cortex enforces a no-access sharing model. This means that without defined ACL, users cannot create, read, update, or delete any data through the API. That is, until the ability to do so is granted through ACL definitions in custom objects and in extensible standard objects.
Standard objects such as the Account Object come pre-defined with Create ACL and Default ACL that enforce a private sharing model.
In a private-sharing model, data is only available to the creator/owner and no one else. In this model, there are only two ways for a user to gain access to another user's data:
- 1.The owner of the data shares that data with another user directly using Connections.
- 2.Access to the data is granted to a subset of users (such as through ACLs)
The following ACL definitions make up a typical private-sharing implementation for an object.
type: 1specifies the target is an Account, and the
target: "000000000000000000000003"is the system identifier for any user in the org. So this ACL is specifying that any authenticated user can create instances of this object.
type: 4is specifying that the target is the instance Owner, and the
allow: 7specifies that the Owner is granted Delete access.
shareChain: [6, 5, 4, 2]
This share chain specifies that access levels of update (6), share (5), read (4), and connected (2) can be used in connections. Because it is a share chain, a user can create a connection with one of these allow levels as long as it is less than his/her own.
Create ACLs determine who in an Organization can create new object instances. Conversations, for example, can only be created by accounts with the Provider role. An object's create acl can be defined in custom objects and augmented or even overwritten in extensible standard objects.
In the case of Create ACL,
allowis not provided in the definition since create access is already implied.
Each Object has it's own set of default rules that determine the level of access users get to object instances. For example, the Account Object default acl allows the account holder Update access to themselves. These defaults can be defined in custom objects and augmented or even overwritten in extensible standard objects.
Share ACLs define how an object instance can be shared. The target in a share ACL entry can be an account, role, owner, or another access level. The allow in a share ACL entry then specifies what role or access level that target is allowed to grant when sharing an object instance via a connection. When share ACL rules are defined, share chains no longer apply.
Example Share ACL
type: 5is specifying the target is an access level. This means that a user with an access level of
7(Delete) to the instance can grant up to access level
6(Update) to another user via a connection.
type: 4is specifying the target is the instance owner and that the owner can grant the provider role (role _id "000000000000000000000005") via a connection. This means that any defaultAcl defined for the provider role in the object definition will be granted to the connected user for that object instance even though they may not have the provider role assigned to their user account.
type: 3is specifying the target is a role. We've created some custom roles of Manager (role _id "5532e499540b0183799b4ee5") and Reporter (role _id "58e96eb0105ddf010067046b"). In the share ACL rule, we are specifying that the Manager role can grant the Reporter role to another user for an object instance via a connection.
The share chain for each Object controls the access level that can be granted to a user through a Connection. A user with enough access to create a Connection can grant any level of access in the object's Share Chain as long as it is lesser than their own.
For example, a user who creates a Patient File is granted Delete access through the object's default ACL. That use can then grant others Share or Connected access to the context. Subsequently, a connected invitee with Share access could re-share the context with others, but only grant Connected access.
The share chains for each object are listed in their descriptions.
There are three standard roles: Admin, Provider and Developer. An Organization can create custom roles, and assign access controls to these. Custom roles can be also be includes within each other. All accounts holder a role are also assumed to hold the included roles.
Creating custom roles can easily be done under Settings > Roles. Creating a new custom role simply requires providing a role name.
Custom roles can also be hierarchical. For example you can create a custom role and specify that it includes other roles.
Once your custom role is created, it's available to be used in Access Controls as well as in scripts via the Consts Module
Object properties have ACLs that determine the access required to create, read, update and delete properties. An Organization can also augment read and update access settings for individual properties with custom ACLs. Commonly, properties required with connected access to read and Update access to update.