Visibility Filters Overview

Visibility Filters are policies that you can implement to control which resources users can view in the EmpowerID user interface. These policies include the following:

• Visibility Restriction policies,

• Column Visibility Filter policies, and

• Data Visibility Filter policies.

Visibility Restriction Policies

Visibility Restriction policies control which data is returned to users from the EmpowerID Identity Warehouse. These policies are similar to RBAC delegations in that you can assign them to any EmpowerID Actor, such as a Management Role, group, Query-Based Collection (SetGroup), and so forth. Once the policy is assigned to an actor, any person belonging to that actor (e.g., members of the IT Manager Management Role) receives the policy.

For example, if your organization uses the services of contractors, you could create a Visibility Restriction policy that allows contractors to see only other contractors within the organization, and apply that policy to a group or Management Role designated for Contractors. Then, when a contractor who belongs to that group or role logs in, they will only be able to see other contractors.

Visibility Filter Policies

Visibility Filter policies are SQL statements written against the EmpowerID Identity Warehouse that give you power and flexibility in determining which users can view what objects. They even allow you to specify the visibility of individual attributes, without concern for the complexities of location-based delegations. You can assign Visibility Filter policies to any EmpowerID Actor type, such as a Management Role, Business Role and Location, group, or Set Group, and to individual accounts and people.

Visibility Filter Policies come in two types, the Column Visibility Filter policy and the Data Visibility Filter policy. Column Visibility Filters and Data Visibility Filters are SQL-based filters that you write against the EmpowerID Identity Warehouse to show and hide data at the column and attribute level. 

Column Filter Policy

The Column Filter Policy is a SQL Select Clause written against an EmpowerID component or object type, such as an account. It specifies what attributes of the component someone with the policy can view. 

For example, one of the Column Filter Policies included with EmpowerID is the "Sample removal of name" policy. This policy hides the true value of each person’s FirstName and LastName attributes, replacing them with "***" so that assignees of the policy will see "***" as the name for any people they view.

The following code snippet shows how to write the substitution for the email in the filter.

EmpowerID includes the following Column Filter Policy that you can use out of the box.

Data Filter Policy

The Data Filter Policy is a SQL Select Statement written against an EmpowerID component or object type, such as a Person, that places limits on the number of objects of that type that can be viewed by someone with the policy. For example, one of the sample Data Filter Policies included with EmpowerID is a Data Filter for the Person object that only allows a person to view people in or below their location. This means that if a person is located in Boston and has this filter through some type of assignment, the person only sees people in the Boston location (or locations below Boston).

EmpowerID includes the following Data Filter Policies that you can use out of the box. 

Filter Precedence

Users can have more than one Visibility Filter policy and you can use combinations of both to create policies that are as granular as needed. For example, you can use the above-mentioned Data Filter policy to allow users to only see people in their location and then add to a subset of those same users a Column Filter policy that replaces the PersonID attribute with "N/A." Users with both policies can see the same number of people; the difference is users with just the Data Filter policy can see email addresses, while users with both policies cannot.

When assigning multiple Visibility Filter policies like these to users, EmpowerID uses the following rules to determine filter precedence:

1. Filters assigned directly to a person have priority over any filter assignments that person receives via RBAC, such as belonging to a Management Role with different filter criteria. For example, if you have a global Visibility Filter that allows someone to view all fields in all HR records for every employee within an organization and assign that filter directly to a person who has a Management Role with a Visibility Filter that limits the number of fields that can be viewed in a given location, the global Visibility Filter takes precedence (because it was directly assigned to the person) and the person will be able to view all fields on all HR records in any location.

2. Filters with the lowest priority value (such as a filter with a priority of 1) take precedence over similar filters with a higher priority value (such as a filter with a priority of 50). Thus, if you want filters to have an accumulative effect, that is, if you want all filters assigned to an actor to have the same level of precedence, those filters must all have the same priority value.

Next Steps

Create Data Filter Policies - Demonstrates how to apply Visibility Filter policies to hide user attributes from those assigned the policy.

Create Column Filter Policies - Demonstrates how to apply Visibility Filter policies to a location so that the resources outside of that location are hidden from users with the policy.