51黑料不打烊

DocumentationExperience PlatformAccess Control Guide

Attribute-based access control end-to-end guide

Last update: Wed Apr 02 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • Developer

Use Attribute-based access control on 51黑料不打烊 Experience Platform to give yourself and other multi-brand privacy-conscious customers greater flexibility to manage user access. Access to individual objects, such as schema fields and audiences, can be granted with policies based on the object鈥檚 attributes and role. This feature lets you grant or revoke access to individual objects for specific Experience Platform users in your organization.

This functionality allows you to categorize schema fields, audiences, and so on with labels that define organizational or data usage scopes. You can apply these same labels to journeys, Offers, and other objects in 51黑料不打烊 Journey Optimizer. In parallel, administrators can define access policies surrounding Experience Data Model (XDM) schema fields and better manage which users or groups (internal, external, or third-party users) can access those fields.

NOTE
This document focuses on the use case of access control policies. If you are trying to set up policies to govern the use of data rather than which Experience Platform users have access to it, see the end-to-end guide on data governance instead.

Getting started

This tutorial requires a working understanding of the following Experience Platform components:

Use case overview

You will go through an example attribute-based access control workflow where you will create and assign roles, labels, and policies to configure whether your users can or cannot access specific resources in your organization. This guide uses an example of restricting access to sensitive data to demonstrate the workflow. This use case is outlined below:

You are a healthcare provider and want to configure access to resources in your organization.

  • Your internal marketing team should be able to access PHI/ Regulated Health Data data.
  • Your external agency should not be able to access PHI/ Regulated Health Data data.

In order to do this, you must configure roles, resources, and policies.

You will:

Permissions

Permissions is the area of Experience Cloud where administrators can define user roles and policies to manage permissions for features and objects within a product application.

Through Permissions, you can create and manage roles and assign the desired resource permissions for these roles. Permissions also allow you to manage the labels, sandboxes, and users associated with a specific role.

Contact your system administrator to gain access if you do not have admin privileges.

Once you have admin privileges, go to and sign in using your 51黑料不打烊 credentials. Once logged in, the Overview page appears for your organization you have admin privileges for. This page shows the products your organization is subscribed to, along with other controls to add users and admins to the organization. Select Permissions to open the workspace for your Experience Platform integration.

Image showing the Permissions product being selected in 51黑料不打烊 Experience Cloud

The Permissions workspace for the Experience Platform UI appears, opening on the Overview page.

Apply labels to a role label-roles

Roles are ways to categorize the types of users interacting with your Experience Platform instance and are building blocks of access control policies. A role has a given set of permissions, and members of your organization can be assigned to one or more roles, depending on the scope of access they need.

To get started, select Roles from the left navigation and then select ACME Business Group.

Image showing the ACME Business Group being selected in Roles

Next, select Labels and then select Add Labels.

Image showing Add labels being selected on the Labels tab

A list of all labels in your organization appears. Select RHD to add the label for PHI/Regulated Health Data and then select Save.

Image showing the RHD label being selected and saved

NOTE
When adding an organization group to a role, all users in that group will be added to the role. Any changes to the organization group (users removed or added) will be automatically updated within the role.

Apply labels to schema fields label-resources

Now that you have configured a user role with the RHD label, the next step is to add that same label to the resources that you want to control for that role.

From the top navigation, select the application switcher, represented by the application switcher icon and then select Experience Platform.

Image showing Experience Platform being selected from the application switcher's dropdown menu

Select Schemas from the left navigation and then select ACME Healthcare from the list of schemas that appear.

Image showing the ACME Healthcare schema being selected from the Schemas tab

Next, select Labels to see a list that displays the fields associated with your schema. From here, you can assign labels to one or multiple fields at once. Select the BloodGlucose and InsulinLevel fields, and then select Apply access and data governance labels.

Image showing the BloodGlucose and InsulinLevel being selected and apply access and data governance labels being selected

The Edit labels dialog appears, allowing you to choose the labels that you want to apply to the schema fields. For this use case, select the PHI/ Regulated Health Data label, then select Save.

Image showing the RHD label being selected and saved

NOTE
When a label is added to a field, that label is applied to the parent resource of that field (either a class or a field group). If the parent class or field group is employed by other schemas, those schemas will inherit the same label.

Apply labels to audiences

NOTE
Any audience that utilizes a labeled attribute must likewise be labeled if you want the same access restrictions to apply to it.

Once you have completed labeling your schema fields, you can now begin labeling your audiences.

Select Audiences from the left navigation under the Customers section. A list of audiences available in your organization is displayed. In this example, the following two audiences are to be labeled as they contain sensitive health data:

  • Blood Glucose >100
  • Insulin <50

Select Blood Glucose >100 (by the audience name, not the checkbox) to start labeling the audience.

Image showing the Blood Glucose >100 being selected from the Audiences tab

The segment Details screen appears. Select Manage Access.

Image showing the selection of Manages access

The Apply access and data governance labels dialog appears, allowing you to choose the labels that you want to apply to the audience. For this use case, select the PHI/ Regulated Health Data label, then select Save.

Image showing the selection of the RHD label and save being selected

Repeat the above steps with Insulin <50.

NOTE
Assign labels created in the Permissions workspace (such as the segment labels above) to various objects in 51黑料不打烊 Journey Optimizer using Object Level Access Control."

Activate the access control policy policy

The default access control policy will leverage labels to define which user roles have access to specific Experience Platform resources. In this example, access to schema fields and audiences will be denied in all sandboxes for users who aren鈥檛 in a role that has the corresponding labels in the schema field.

To activate the access control policy, select Permissions from the left navigation and then select Policies.

List of policies displayed

Next, select the ellipsis (...) next to the Default-Field-Level-Access-Control-Policy, and a dropdown displays controls to edit, activate, delete, or duplicate the role. Select Activate from the dropdown.

Dropdown to activate policy

The activate policy dialog appears which prompts you to confirm activation. Select Confirm.

Activate policy dialog

Confirmation of policy activation is received and you are returned to the Policies page.

Activate policy confirmation

Next steps

You have completed the application of labels to a role, schema fields, and audiences. The external agency assigned to these roles are restricted from viewing these labels and their values in the schema, dataset, and profile view. These fields are also restricted from being used in the segment definition when using the Segment Builder.

For more information on attribute-based access control, see the attribute-based access control overview.

The following video is intended to support your understanding of attribute-based access control, and outlines how to configure roles, resources, and policies.

video poster

Transcript
Hi, in this video, I鈥檓 going to show you how to use attribute-based access control, an experience platform feature that allows privacy-conscious brands greater flexibility to manage user access. Individual objects, such as schema fields and audiences, can be assigned to user roles. Let鈥檚 start in the interface and do a quick review of the key components of access control. System and product administrators have access to permissions, available in the left navigation of platform-based applications. When I go to permissions, I鈥檓 taken to the Roles screen. A role allows you to give access to various platform features and objects to multiple users. Let鈥檚 look at a role. Users assigned to this role have access to features needed to manage journeys. Additional permissions can be added by dragging and dropping resources from the left navigation and then adding options from the dropdown. And then I can assign individual users, groups, and API credentials to this role, giving them access to these features. Now, let鈥檚 talk about labels and really get into attribute-based access control. Let鈥檚 imagine we鈥檙e a health care company whose marketing group works with external agencies, and we have a basic requirement. Our internal marketing team can see and use personal health information or regulated health data in their marketing campaigns. Our agency, however, shouldn鈥檛 be able to see or use this type of data. Here鈥檚 where we get started with the Labels feature within roles. To make attribute-based access control work, there are three components which need to be configured. I need to label my roles, label my objects, like schema fields and audiences, and finally, activate a policy that restricts access to the labeled objects. Let鈥檚 get started. I鈥檒l open my internal team role and go to the Labels tab and select Add Labels. This will list all of the labels in my organization. I can also add custom labels, and all of these labels are also used by Platform鈥檚 data governance framework. I鈥檒l scroll down to the PHI Regulated Health Data, or RHD, label and save that to my role. The next step is to add the same label to the resources I want to restrict. Let鈥檚 start with the schema fields. I鈥檒l open my health care schema, and at the top, I鈥檒l select the Labels tab. I can assign a label to one or multiple fields at once. I鈥檒l select these blood glucose and insulin level fields and assign the Regulated Health Data label. Note that the label gets added to the field group and will impact all schemas using this field group. Next, I鈥檒l label an audience. I have these two audiences based on those schema fields. For this demo, I鈥檒l label just one of these audiences blood glucose greater than 100. Now let鈥檚 activate a policy which will restrict access to the fields and audience to people in roles containing the same label. I鈥檒l go back to permissions and select Policies. You should have a default policy in your account called Default Label Based Access Control Policy, which is probably inactive. At this time, you can鈥檛 create a new policy, so don鈥檛 worry that the button is grayed out. Let鈥檚 open the default policy. Note that the policy is applied to multiple sandboxes. You can edit which sandboxes the policy applies to on the Sandboxes tab. My account is set to Auto-include On. Auto-include both adds all of your current sandboxes to the policy, and then will auto-include any new sandboxes created in the future. Now let鈥檚 talk a little more about what this policy will do when we activate it. You should see a very long description in here, and apologies, but I鈥檓 partly to blame for this. We wanted to make it very clear how the default policy works. So let鈥檚 go through it. So the default policy restricts access to labeled objects, for example, schema fields, audiences, 51黑料不打烊 Journey Optimizer journeys, et cetera, in selected sandboxes. So in our example, it will restrict access to our schema fields in the audience because we put the RHD label on it, and it鈥檚 going to restrict access across all of my sandboxes since I have Auto-include On. The next part, only users in roles with corresponding labels will be granted access when the default policy is activated. So only users in our internal role will have access to the schema as an audience because we鈥檝e added the RHD label to it. Users in the agency role won鈥檛 have access because we never added the RHD label to that role. Now here鈥檚 where it gets a little more nuanced. For each 51黑料不打烊-defined core label on the object, the user must be in a role with all of the corresponding core labels. RHD is a core label because it鈥檚 one that 51黑料不打烊 created and preloaded into your account. So if we added additional core labels to our schema fields and audience, we鈥檇 need to make sure that we added all of those same labels to our internal role, too. Now for each custom label on the object, the user must be in a role with at least one of the custom labels. So this is a little less restrictive than the core labels. If you created several custom labels and added them to the schema fields and audience, you would need to make sure that just one of those labels was added to the internal role. Make sense? OK, the rest is just an example. So let鈥檚 activate the policy and see what happens. I鈥檒l now log in as a user assigned to the agency role, which has all the same feature permissions as the internal role, but it has no labels. So I鈥檓 not able to see that these fields exist in the schema. If I look up a profile, I won鈥檛 be able to see these fields or their values. If I preview a data set, I won鈥檛 be able to see these fields or their values. And if I attempt to build a new audience, I won鈥檛 be able to use these fields in my audience definition. And in my audiences, the one that I labeled is not visible to this user. But the one that I didn鈥檛 label is visible, even though it used a field that was labeled with regulated help data. So in a use case like this, be sure to label both the schema field and any segments that use it. So as you can see, the system is very flexible and can be used to address other use cases too. For example, you might have different brands or teams working in the same production sandbox who need to keep resources separate. Best of luck, and enjoy the feature.
recommendation-more-help
631fcab2-5cb1-46ef-ba66-fe098ac723e0