Create Permissions in the UI¶
Permissions allow your organization to grant access to catalog, database, dataset, role,
Who Can Create Permissions?¶
Catalog administrators and users with the ability to grant access (
Include ability to grant checkbox selected) for at least one data object can grant permissions to roles.
Users can only grant permissions to roles for which they have grant access (defined by having
MANAGE_PERMISSIONS for those
This launches the permission dialog that prompts you to provide information about the new permission.
Note: When you access this dialog from the Roles page, the role to which the permission applies is already selected because you selected a role to access the dialog. When you access this page from the Permissions tab on the Databases page (after selecting a dataset), both the database and dataset are already selected because you selected them to access the dialog. The following sample screen was accessed from the Roles page.
Basic information that must be supplied for a permission include:
- The role to which the permission applies. This is the role to which the permission grants access.
- The access level that should be granted. Select the degree of access to data granted to the role. The access level you select may affect what other options are available. To learn more about access levels, see Privileges. To create an ABAC permission, select the SELECT access level and add access conditions to your permission. Learn more about access conditions in the Adding Access Conditions.
- The data objects to which the permission applies. Use the Scope dropdown to select the type of data object to which the permission grants access (catalog, database, dataset, URI, namespace attribute, role or data connection). Certain scopes may not be available depending on your access to data, and the access level you have selected. Once you have specified a scope, select the specific data object to which the permission grants access. This dropdown is limited to the objects for which you have the Include ability to grant checkbox selected.
Optional information that can be specified in a permission definition includes:
As you supply field values on the permissions dialog, the permission summary updates to show you a preview of your permission in both text and SQL. Use the View as SQL and View as text toggle buttons in the summary to switch between views:
After you have supplied values for all required fields and confirmed that your permission looks correct in the policy summary, select to grant this new access to the role.
Add Access Conditions¶
Access conditions allow you to filter or transform the data to which you are granting access. This allows you to provide more secure access. To add an access condition, select Add an access condition:
There are three types of access conditions:
- Restrict access based on tags
- Transform data
- Restrict access with row filtering
Restrict Access Based on Tags¶
Select the Restrict access based on tags condition to limit access to data based on how the data is tagged. After selecting this condition, select either the tagged or not tagged option. Selecting tagged grants access only to data objects with specific tags; selecting not tagged prevents access to data objects with specific tags.
In the Following example, the selected role only has access to objects in the sales database that are tagged
In the following example, the selected role has access to all objects in the sales database except those tagged
See Managing Tags for more information about creating and assigning tags to data.
Select the Transform data condition to use masking or tokenizing to obscure tagged data or change how it appears for the selected role.
The Tags dropdown lets you select the tagged data you want to transform, and the Transform type dropdown lets you select the type of transformation to apply to the data.
In the following example, the selected role has access to all data objects in the sales database, but data for objects tagged
pii: email_address is masked.
Several basic transform types can be performed, but if you want to transform data with a different type or with a more complicated expression, select the
Custom SQL transform type and use a custom SQL expression for the transformation.
Note: Transforming data is not the same as restricting access to data. If you add a Transform data condition to your permission, the role still has access to the transformed data, but only sees an obscured version of the data when they access it.
The following example shows what a role would see if columns tagged
pii: credit_card were masked with a Transform data condition:
Restrict Access With Row Filtering¶
Select the Restrict access with row filtering condition to limit access to data based on the content of the data itself.
In the following example, the selected role only has access to data in the
sales database where columns named
state_s have a value of
The following image shows what this role (with row filtering on its permission) would see when previewing a dataset in the
sales database (on the right) compared to what an administrator would see (on the left):
To learn more about implementing column- and user-attribute-based access conditions with row filtering see Creating Row-Level Security Permissions.
Add Multiple Access Conditions¶
You can add multiple access conditions to a permission, but there are some limitations on which conditions may be added in succession.
You cannot repeat tags within condition types. Each tag can only be used once per condition type. For example, if you apply a mask transformation to data tagged
pii: email_address, you cannot also apply a tokenize transformation to data tagged
pii: email_address. This avoids logical conflicts within conditions.
You cannot repeat Restrict access based on tags condition types. You can add a maximum of two Restrict access based on tags conditions per permission: one with the tagged option and one with the not tagged option. This avoids redundant and potentially confusing permissions.
You can only add one Restrict access with row filtering condition type. You can add only one Restrict access with row filtering condition type. However, you can create a Restrict access with row filtering condition type that contains multiple condition clauses that are joined into a single condition. This avoids redundant and potentially confusing permissions.
Because of these limitations, certain permissions added via the Workspace or created prior to Okera 2.1 are not available for editing. To learn more about editing and managing permissions, see Editing Permissions.
Set Time-Based Conditions¶
You can restrict the date and times a permission definition is active for a role. In the Time-based conditions section of the permission dialog, select Set a permission start date to specify the start date and time for a permission definition. Select Set a permission end date to specify the end date and time on which the permission definition should be active. The permission definition is only enforced during the specified date and time range.
Select the calendar icon () in the Start date/time and End date/time boxes to select start and end dates. A date-time dialog appears with tabs for date and time.
To use the date-time dialog:
Use the date tab to select a date on the calendar for the start or end date.
To set the start or end time, select the hour or minute in the box at the top or select the clock tab. A clock appears in the bottom part of the dialog. In the box above the clock, select the time part (hour or minute) you want to change. Use the dial on the clock to set the hour or minute. Then select AM or PM in the box above the clock.
When the date and time have been set correctly, select OK.
You can specify only a start date and time or only an end date and time. If you specify both, the end date and time must be later than the start date and time.
Permission lists show upcoming start or end times for permissions in the Warnings column. For example:
Creating a new permission may sometimes generate a conflict warning, as shown below:
For information on permission conflicts, see Permission Conflicts.