Attribute-based access control overview

Hi, in this video, I’m 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’s 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’m 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’s 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’ll 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’s talk about labels, and really get into attribute-based access control. Let’s imagine we’re 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’t be able to see or use this type of data. So here’s 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’s get started. I’ll 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’ve used the platform’s governance framework, this list will look familiar. I’ll 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’s start with schema fields. I’ll open my healthcare schema. And at the top, I’ll select a labels tab. I can assign a label to one or multiple fields at once. I’ll 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’ll add the label to a segment. I have these two segments based on those schema fields I just labeled. For this demo, I’ll label just one of the segments, blood glucose is greater than 100. I’ll open the segment and click manage access. And then I add the label just like before. There’s also a managed access button in the segment editor. Now let’s 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’ll 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 Adobe, it’s considered a core label, and I’ll choose core label for my resource. Note that I don’t select individual labels that were on the list.

So what this means is if the user in the schema field don’t have matching labels, don’t 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’ll save it, and then activate my policy. So what did this do? I’ll now log in as a user assigned to the agency role, which has the exact same feature permissions, but no labels.

I’m not able to see that these fields exist in this schema. If I look up a profile, I won’t see these fields or their values. If I preview a data set, I won’t see these fields or values. And if I attempt to build a new segment, I won’t 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’t 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. -