Visibility Filters Overview
- Universal Importer for Confluence
- Kim Landis (Unlicensed)
In previous versions of EmpowerID, users could not see resources within their own organizations without an RBAC assignment. For example, a user could not look up information about users within their office until they were granted the Viewer Access Level for each of those users. This is no longer the case as RBAC control over the visibility of resources has been replaced by three types of policies:
- Visibility Restriction policies,
- Column Visibility Filter policies, and
- Data Visibility Filter policies.
Visibility Restriction policies most resemble RBAC and are easy to implement. EmpowerID recommends using these policies in most cases.
Visibility restriction policies do not affect the EmpowerIDAdmin user.
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. These offer flexibility and power, allowing you to show and hide data at the column and attribute level. However, as they are more difficult to implement, only use them when Visibility Restriction policies cannot cover your use case.
Each of these policy types are discussed in greater detail below.
Visibility Restriction Policies
You can create Visibility Restriction policies to limit the ability of people to view resources in EmpowerID. 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.
For help in applying Visibility Restriction policies, see Creating Visibility Restriction Policies.
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 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 AccountView removing visibility on email" policy. This policy hides the true value of each user account's Email attribute, replacing it with "N/A" so that assignees of the policy will see "N/A" as the Email address for any user accounts they view.
The following code snippet shows how to write the substitution for the email in the filter.
'N/A' AS Email, [TABLEALIAS].*
EmpowerID includes the following Column Filter Policy that you can use out of the box.
| Column Filter Policy | EmpowerID Component | Purpose | Assignee Type |
|---|---|---|---|
| Sample AccountView removing visibility on email | Account | Substitutes the actual value of the email attribute on an account with "N/A" for anyone assigned the filter. | Empty |
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).
| Data Filter Policy | EmpowerID Component | Purpose | Assignee Type |
|---|---|---|---|
| Anonymous user cannot see anyone | Person | Anonymous users cannot see anyone in EmpowerID | Person |
| Sample filter for Account (see only accounts in or below my locations) | Account | Filters the accounts that can be viewed in EmpowerID to include only those in the assignee's location or below | Empty |
| Sample filter for Account (see only own accounts) | Account | Assignees cannot view any accounts in EmpowerID beyond their own | Empty |
| Sample filter for Business Roles (see only business roles in a list) | OrgRole | Filters the business roles that can be viewed in EmpowerID to include only those specified | Empty |
| Sample filter for Computer (see only computers in or below my locations) | Computer | Filters the computers that can be viewed in EmpowerID to include only those in the assignee's location or below | Empty |
| Sample filter for Groups (see only groups in a list) | Group | Filters the groups that can be viewed in EmpowerID to include only those specified | Empty |
| Sample filter for Groups (see only groups in a specific OU) | Group | Filters the groups that can be viewed in EmpowerID to include only those in a specified OU | Empty |
| Sample filter for Groups (see only groups in or below my locations) | Group | Filters the groups that can be viewed in EmpowerID to include only those in the assignee's location or below | Empty |
| Sample filter for Groups (see only groups I belong to) | Group | Filters the groups that can be viewed in EmpowerID to include only those to which the assignee belongs | Empty |
| Sample filter for Locations (see only locations below my locations) | Location | Filters the locations that can be viewed in EmpowerID to include only those below the assignee's locations | Empty |
| Sample filter for Management Role (see only management roles in a list) | Management Role | Filters the management roles that can be viewed in EmpowerID to include only those specified | Empty |
| Sample filter for Management Role (see only management roles in a location) | Management Role | Filters the management roles that can be viewed in EmpowerID to include only those in the location specified | Empty |
| Sample filter for Management Role (see only management roles in or below my locations) | Management Role | Filters the management roles that can be viewed in EmpowerID to include only those in or below the assignee's locations | Empty |
| Sample filter for Management Role Definition (see only management role definitions in a list) | Management Role Definition | Filters the management role definitions that can be viewed in EmpowerID to include only those specified | Empty |
| Sample filter for Person (see only self) | Person | Assignees cannot view anyone in EmpowerID beyond their own person | Empty |
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:
- 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.
- 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.
If several filters use the same priority for the same object and mode, and could potentially be applied to a person, they should not have conflicting SQL variables (variables with the same name declared in the Pre-Query; otherwise a SQL exception will occur for that query.)
- Creating Data Filter Policies - Demonstrates how to apply Visibility Filter policies to hide user attributes from those assigned the policy.
- Creating 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.