Partilhar via


ACL Overview

Certain entities in your system may be visible to some users and not others. These security policies are represented as access control lists (ACLs) in the Middleware Platform.

ACLs consist of two parts - atsEntityAcls and atsEntityAclAssignees . You will create atsEntityAcl records to associate your entities with security groups or roles in your system. Then, you'll create atsEntityAclAssignee records to associate your users with security groups or roles in your system for a specific entity type.

The visibility of your customer's synced entities within LinkedIn products will depend on the ACLs you sync. Before syncing ACLs, there are a few steps you must complete:

  1. Configure entity visibility defaults for the customer
  2. Bind the customer's users with LinkedIn Person Ids
  3. Sync ACLs

Details for each step are below.

1. Configure Customer Entity Visibility Defaults

You can control whether the absence of atsEntityAcl records will cause securable entities to be hidden from all users or not. For example, if a customer doesn’t secure entities in your system, you may choose to not send atsEntityAcl records and have LinkedIn products show entities without ACLs to all users. This can be configured per LinkedIn product ( tenantType ) and feature ( integrationType ).

See Sync Integration Configurations for technical details on configuring the customer. Also, be sure to send visibility default configurations for each relevant integrationType to ensure the entity doesn't surface anywhere in the product.

sample request

Headers:

Authorization: Bearer {token}
x-restli-method: batch_update

Request Body:

{
  "entities": {
    "JOB_POSTING_VIEWERS": {
      "configurationValue": {
        "string": "ALL_PRODUCT_USERS"
      }
    }
  }
}

Note

We will hide entities without atsEntityAcl records by default. Do not create (or do delete) this configuration if this behavior is desired for the customer.

2. Bind Customer Users

You must store a mapping to a LinkedIn Person Id for each user in your system. This Person Id will be used to specify the target of this security rule when syncing atsEntityAclAssignee records.

See Bind Customer Users for technical details.

3. Sync ACLs

You should sync ACLs in the following scenarios:

  • During the historical data sync after a customer onboards
  • When a secured entity is created, deleted, or its security info is modified in your system
  • When a customer user is created, deleted, or its security info is modified in your system

See Sync ACLs for technical details.