Skip to content

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 ALL or MANAGE_PERMISSIONS for those ROLE objects).

Create Permissions

Permissions can be created on the Roles page after selecting a role or on the Permissions tab on the Databases page after selecting a database or dataset. Select to add a permission.

Create a Permission

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.

Add Permission Dialog

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 Add 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:

Permission Summary Toggle

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:

Add Access Condition

There are three types of access conditions:

  • Restrict access based on tags
  • Transform data
  • Restrict access with row filtering

Access Condition Selection

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 location: usa.

Tagged condition

In the following example, the selected role has access to all objects in the sales database except those tagged pii: phone_number.

Not tagged condition

See Managing Tags for more information about creating and assigning tags to data.

Transform 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.

Transform Condition

Several basic transform types can be performed. See Privacy and Security Functions for descriptions of the different transformation types.

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.

Custom SQL Condition

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:

Transformed Data Preview

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 CA.

Where Clause Filter Condition

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):

Where clause preview

To learn more about implementing column- and user-attribute-based access conditions with row filtering see Creating Row-Level Security Permissions.

Row Filtering by Column Name or Column Tag

You can perform row filtering based on a column name or a column tag. Using a column tag for filters provides more flexibility and is easier to set up.

For example, suppose one dataset in a database includes a column named country (populated with country names) and another dataset in the database includes a column named nation (also populated with country names). If you create permissions based on the column name, you will have to create two permissions, one for each unique column name. But if you tag the country and nationcolumns with a tag named company.location (for example) and create permissions based on the tag name, only a single permission is necessary at the database level to cover both datasets.

Column tags can be filtered for values or for user attributes. For example, you could create a row filter for the company.location column tag that provides access only where the value equals France or where the value matches the user attribute country.

To filter by column name, select Column in the Only grant access to data WHERE... box. To filter by column tag, select Column with tag in the Only grant access to data WHERE... box.

Note: At this time, you cannot specify more than one tag-based row filter in a single permission.

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.

Time-Based Conditions

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.

Date-Time-Dialog

To use the date-time dialog:

  1. Use the date tab to select a date on the calendar for the start or end date.

  2. 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. Clock-Dialog

  3. 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:

Permission Start and End Times

Permission Conflicts

Creating a new permission may sometimes generate a conflict warning, as shown below:

Conflict Error

For information on permission conflicts, see Permission Conflicts.