This guide describes how to organize and manage user metadata, which is used by Immuta to identify users targeted by policy.

No matter if you choose orchestrated RBAC or ABAC as described in the Governance use cases introduction, you must have metadata on your users. This can be done in Immuta, via your identity manager, or other custom sources.

Doing so allows you to build scalable policies that do not reference individual users and instead use metadata about them to target them with access decisions. In Immuta, user metadata is termed user attributes and groups.

Considerations

Referring back to our triangle of access decision, user metadata is the first point of that triangle. User metadata is made up of the following elements:

• Attributes: key:value pairs tied to your users

• Groups: a single value tied to your users - you can think of groups as containing users. Groups can also have their own attributes, a shortcut for assigning attributes to all members of a group. In either case, multiple users can be attached to the same attribute or group.

Referring back to will help drive how you manage user metadata.

Fact-based user metadata (ABAC) allows you to decouple policy logic from user metadata, allowing highly scalable ABAC policy authoring:

• Steve has attribute: country:USA

• Sara has attribute: role:administrator

• Stephanie has attribute: sales_region: Ohio, Michigan, Indiana

Logic-based user metadata (orchestrated-RBAC) couples user metadata with access logic:

• Steve has attribute: access_to:USA

• Sara has attribute: role:admin_functions

• Stephanie has groups: Ohio_sales, Michigan_sales, Indiana_sales

Typically these groups (most common) and attributes come from your identity management system. If they do, they also potentially contain access logic as part of them (examples in the logic-based user metadata list above). It’s not the end of the world if they do, though this means you are potentially set up for . If each group from your identity management system represents a single static fact that provides access for a set of objects, with no overlap with other facts that provide access - then you can use orchestrated RBAC. A simple example to demonstrate groups ready for orchestrated RBAC is “you must have signed license agreement x to see data tagged x” - it’s a simple fact: you’ve signed license agreement x, that provides access to data tagged x. There are no other paths to data tagged x.

But the key to orchestrated RBAC is that it’s a 1:1 relationship with the group from your identity manager and the set of objects that group gives them access to. If this is not true, and there are multiple permutations of groups that have implied policy logic and that logic provides access to the same sets of objects, then you are in a situation with role explosion. This is a problem that Immuta can help you solve, and you should solve that problem with .

The one exception where you have the above scenario but may want to use orchestrated RBAC is if these multiple paths for access to the same objects are a true hierarchy. For example, data is tagged with Strictly Confidential, Confidential, Internal, and Public:

• users assigned group Strictly Confidential can see data tagged Strictly Confidential, Confidential, Internal, and Public

• users assigned group Confidential can see data tagged Confidential, Internal, and Public

In this case, you could use even though there are multiple paths of access to the same objects because it is a one-to-one relationship represented in a hierarchy that contains all paths. How you actually write this policy will be described later.

Orchestrated RBAC: user attributes and groups

Since orchestrated RBAC is a one-to-one match (or a true hierarchy), you can use your groups as-is from your or other .

Without getting into the details of how the policy is authored (yet), it is possible to leverage a user attribute hierarchy to contribute to access decisions through hierarchical matching. For example, users with attributes that are either a hierarchical parent or an exact match to a given data tag can be subscribed to the data source via a hierarchical match. To better illustrate this behavior, see the matrix below:

So you should take care organizing your user attributes with a hierarchy that will support the hierarchical matching.

Going back to our hierarchical example of Strictly Confidential, Confidential, Internal, and Public above, you would want to ensure that user attributes follow the same hierarchy. For example,

• A user with access to all data: Classification: Strictly Confidential

• A user with access to only Internal and Public: Classification: Strictly Confidential.Confidential.Internal

Remembering the last row in Figure 3, hierarchical matching only happens in a single direction → user attribute contains the data source tag. Since the user attribute is more specific (Strictly Confidential.Confidential.Internal) than data tagged Strictly Confidential and Strictly Confidential.Confidential, the user would only gain access to data tagged Strictly Confidential.Confidential.Internal and Strictly Confidential.Confidential.Internal.Public.

ABAC: user attributes and groups

To use ABAC, you need to divorce your mind from thinking that every permutation of access requires a new role. (We use the word role interchangeably with groups in this document, because many identity and access systems call groups roles, especially when they contain policy logic.)

Instead you need to focus on the facts about your users they must possess in order to grant them access to data. Ask yourself, why should someone have access to this data? It’s easiest to come at this from the compliance perspective and literally ask yourself that question for all the compliance rules that exist in your organization.

Why should someone have access to my PHI data? Example answers might be

• If they are an analyst

• If they have taken privacy training

So, at a minimum, you are going to need to attach attributes or groups to users representing if they are an analyst and if they have taken privacy training. Note you do not have to (nor should you) negate these attributes, meaning nobody should have a group not_analyst and no_privacy_training.

Repeat this process until you have a good starting point for the user attributes you need. This is a lot of upfront work and may lead to the perception that ABAC also suffers from attribute explosion. However, when attributes are well enumerated, there’s a natural limit to how many different relevant attributes will be present in an organization. This differs substantially from the world where every permutation of access is represented with a role, where role growth starts off slow, but increases linearly over time.

As an illustration, well-defined subject attributes tend to follow the red curve over time, while roles and poorly defined subject attributes tend to follow the blue and quickly become unwieldy.

Applying user metadata

Where do those attributes and groups come from? Really, wherever you want - Immuta has several interfaces to make this work, and you can combine them:

Option 1: Store them in your . If you have the power to do this, you should. It becomes the primary source of facts about your users instead of the source of policy decisions, which should not live in your identity manager. We recommend synchronizing this user metadata from your identity manager to Immuta over SCIM where possible.

Option 2: Store them . It is possible to manually add attributes and groups to users directly in the Immuta UI or through the API.

Option 3: Refer to them from some other . For example, perhaps training courses are already stored in another system. If so, you can able to build an external user into endpoint to pull those groups (or attributes) into Immuta. However, there are some considerations with this approach tied to which IAM protocol you use. If your identity manager restricts you from using the approach in the , you can instead periodically push the attributes from the source of truth into Immuta using our APIs.

All of these options assume you have already . This has to be done in order to create the user identities that these attributes and groups will be attached to.

Next steps

Before authoring global subscription policies to automate access controls, user metadata must exist in Immuta so that it can be used in the policy to identify the users that should be granted or revoked access to data.

This how-to guide demonstrates how to manually add groups and attributes or use existing groups in external identity managers to identify users that should be targeted by a subscription policy.

For detailed explanations and examples of how to manage user metadata, see the Managing user metadata guide.

Requirements

Immuta permission: USER_ADMIN

Prerequisite

Select your metadata strategy

• : Use this strategy if you have many variables that determine access.

• : Use this strategy if a

Organize your user metadata

Add user metadata to Immuta

Once you've organized your user metadata, you can add that metadata in Immuta in these ways:

1. Add attributes and groups to users in your identity manager. Then, sync your users, groups, and attributes from your external identity manager to Immuta:

   1. : Enable LDAP sync and sync groups and attributes to Immuta for your provider.

   2. or : Enable SCIM for your provider and enable sync attributes and groups.

Next steps