Configure attribute-based access control

Transcript

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 audiences, 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. When I go to permissions, I’m taken to the Roles screen. A role allows you to give access to various platform features and objects 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, groups, and API credentials to this role, giving them access to these features. Now, let’s talk about labels and really get into attribute-based access control. Let’s imagine we’re 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’t be able to see or use this type of data. 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 objects, like schema fields and audiences, and finally, activate a policy that restricts access to the labeled objects. 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 custom labels, and all of these labels are also used by Platform’s data governance framework. I’ll 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’s start with the schema fields. I’ll open my health care schema, and at the top, I’ll select the 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 to the field group and will impact all schemas using this field group. Next, I’ll label an audience. I have these two audiences based on those schema fields. For this demo, I’ll label just one of these audiences blood glucose greater than 100. Now let’s activate a policy which will restrict access to the fields and audience to people in roles containing the same label. I’ll 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’t create a new policy, so don’t worry that the button is grayed out. Let’s 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’s 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’m partly to blame for this. We wanted to make it very clear how the default policy works. So let’s go through it. So the default policy restricts access to labeled objects, for example, schema fields, audiences, Adobe 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’s 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’ve added the RHD label to it. Users in the agency role won’t have access because we never added the RHD label to that role. Now here’s where it gets a little more nuanced. For each Adobe-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’s one that Adobe created and preloaded into your account. So if we added additional core labels to our schema fields and audience, we’d 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’s activate the policy and see what happens. I’ll 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’m not able to see that these fields exist in the schema. If I look up a profile, I won’t be able to see these fields or their values. If I preview a data set, I won’t be able to see these fields or their values. And if I attempt to build a new audience, I won’t 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’t 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.