Create Permissions in the UI

Permissions allow your organization to grant access to users, based on their Okera role for the catalog, a database, a dataset, an attribute (tag) namespace, a URI, a role, or a data connection. They specify the access levels and conditions for structured and unstructured data objects registered in Okera. When applied to an Okera role, they represent an Okera policy for the 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 Data page after selecting a database or dataset. They can also be created from the Files tab on the Data page and the Files page after selecting a URI.

Alternatively, you can select the button on the Call-to-Action Home page in the Permissions section and follow the prompts. You will be presented with the option to create the permission starting with a role or starting with the data object.

After selecting Start with a role or Start with the data and selecting , either the Roles or Data page appears.

On the Roles page, select a role and then select to add a permission.

On the Data page, select:

• A database on the Databases tab if you want the permission applied to the entire database. Then select the Permissions tab.
• A dataset (after selecting a database on the Databases tab and the dataset on the Databases page for the selected database) if you want the permission applied to an individual dataset. Then select the Permissions tab.
• A URI on the Files tab if you want the permission applied to an unstructured data URI.

Then select to add a permission. This launches the Create permission dialog that prompts you for 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 Data page (after selecting a database, dataset, or URI), the database, dataset, or URI 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 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:

• Access conditions
• Time-based conditions

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

Note: When creating permissions for unstructured data URIs, the only access condition you can specify is Restrict access based on tags.

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.

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

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.

Several basic transform types (mask, hash/sha2, mask ccn, tokenize, AES encryption, AES decryption, PHI age, PHI date, PHI data of birth, PHI zip code, null, and zero) can be selected from the UI. See Privacy and Security Functions for descriptions of these 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.

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 a ccn column is tagged pii: credit_card and transformed using the Mask transform type:

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.

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.

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: When a column is chosen as the filter source and the row-level filter is applied at the database level, tables that do not contain the referenced column are no longer accessible. If a Column with tag (columns_with_attribute) is chosen as the filter source, all tables are accessible and the row-level filter permissions are applied accordingly.

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.

Click in the Start date or End date boxes to select start or end dates. A date-time dialog appears with tabs for date and time.

To change the start or end times, click the particular section of the time value you want to change in the Start time or End time boxes. For example, to change the hour of the day, select the hour part of the time and change it. To change the time of day (a.m. or p.m.), select the am or pm in the time box and change it to the time of day you want.

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 Conflicts

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

For information on permission conflicts, see Permission Conflicts.