Attribute-based access control end-to-end guide
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 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.
Getting started
This tutorial requires a working understanding of the following Platform components:
-
Experience Data Model (XDM) System: The standardized framework by which Experience Platform organizes customer experience data.
- Basics of schema composition: Learn about the basic building blocks of XDM schemas, including key principles and best practices in schema composition.
- Schema Editor tutorial: Learn how to create custom schemas using the Schema Editor UI.
-
51黑料不打烊 Experience Platform Segmentation Service: The segmentation engine within Platform used to create audience segments from your customer profiles based on customer behaviors and attributes.
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:
- Label the roles for your users: Use the example of a healthcare provider (ACME Business Group) whose marketing group works with external agencies.
- Label your resources (schema fields and audiences): Assign the PHI/ Regulated Health Data label to schema resources and audiences.
- Activate the policy that will link them together: Enable the default policy to prevent access to schema fields and audiences by connecting the labels on your resources to the labels in your role. Users with matching labels will then be given access to the schema field and segment across all sandboxes.
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 Platform integration.
The Permissions workspace for 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 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.
Next, select Labels and then select Add Labels.
A list of all labels in your organization appears. Select RHD to add the label for PHI/Regulated Health Data and then select Save.
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
Select Schemas from the left navigation and then select ACME Healthcare from the list of schemas that appear.
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.
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.
Apply labels to audiences
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.
The segment Details screen appears. Select Manage 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.
Repeat the above steps with Insulin <50.
Activate the access control policy policy
The default access control policy will leverage labels to define which user roles have access to specific 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.
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.
The activate policy dialog appears which prompts you to confirm activation. Select Confirm.
Confirmation of policy activation is received and you are returned to the Policies page.
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.
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 segments 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, or configurable as a quick access link on the Experience Cloud homepage.
When I go to permissions, I鈥檓 taken to the roles screen. Attribute-based access control exists within the larger concept of role-based access control. A role allows you to give access to various platform features 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 in groups to this role to give them access to these features. These users must already be included in your organization. If not, you鈥檒l first need to add them in the admin console, and assign them to at least one product profile before you can add them to a role. You can also assign API credentials, which were created in the developer console, to a role. Now let鈥檚 talk about labels, and really get into attribute-based access control. Let鈥檚 imagine we鈥檙e a healthcare 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 our marketing campaigns. Our agency, however, shouldn鈥檛 be able to see or use this type of data. So 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 resources, like schema fields and segments, and finally build a policy that links those labels together. 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 new ones. If you鈥檝e used the platform鈥檚 governance framework, this list will look familiar. I鈥檒l scroll down to the PHI regulated health data 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 schema fields. I鈥檒l open my healthcare schema. And at the top, I鈥檒l select a 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 at the field group level, and will impact all other schemas using this field group.
Next, I鈥檒l add the label to a segment. I have these two segments based on those schema fields I just labeled. For this demo, I鈥檒l label just one of the segments, blood glucose is greater than 100. I鈥檒l open the segment and click manage access. And then I add the label just like before. There鈥檚 also a managed access button in the segment editor. Now let鈥檚 create a policy to link the labels in the attributes to the labels in my role. I go back to permissions, and select policies, and I鈥檒l create a new policy.
Note that if I click this arrow, it flips the logic from deny to permit, but I want to stick with deny. I select my resource, and restrict access to all. Now for my attribute, since the RHD label was provided out of the box by 51黑料不打烊, it鈥檚 considered a core label, and I鈥檒l choose core label for my resource. Note that I don鈥檛 select individual labels that were on the list.
So what this means is if the user in the schema field don鈥檛 have matching labels, don鈥檛 let them access the schema field in all of my sandboxes.
And to include my segments in this policy, I can add another resource.
I鈥檒l save it, and then activate my policy. So what did this do? I鈥檒l now log in as a user assigned to the agency role, which has the exact same feature permissions, but no labels.
I鈥檓 not able to see that these fields exist in this schema. If I look up a profile, I won鈥檛 see these fields or their values. If I preview a data set, I won鈥檛 see these fields or values. And if I attempt to build a new segment, I won鈥檛 be able to use these fields in my segment definition.
And in my segments, the one that I labeled is not visible to this user, but the one that I didn鈥檛 label is visible, even though it uses a field that was labeled with regulated health data. So in a use case like this, be sure to label both the schema field and any segments that use it. 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. So best of luck, and enjoy the feature. -