Skip to content

Viewing and Managing Policies in the UI

Who has access to view permissions on data?

  • Users who have WITH GRANT OPTION on those data objects
  • Users who have any level of access to manage a specific ROLE object can see all permissions granted to that role. They will not be able to edit permissions unless they have WITH GRANT OPTION on the data the permission is granting access on.

Viewing Permissions

Permissions show what data a role has access to and what type of access they have.

You can see permissions on:

  • The role details pane from the Roles page
  • The Permissions tab on the Data page for a database or a dataset.

Permissions table Permissions on the role details pane

This table has several columns:

  • Access: The level of privilege being granted by the permission. To learn more, see Privileges.
  • Scope: The granularity of data that the permission grants access to, i.e. catalog, database, table, or column.
  • Data: The exact data that the permission grants access to. Clicking on the name of a database, table, or column will open its details in a new tab.
  • Conditions: Any access conditions that have been applied to this permission to further filter access. Read more about conditions in Creating Policies in the UI.

Some tables may also have a column named ‘Conflicts’. Read more about this in the Permission Conflicts section below.

URI Grants

If a role has been granted any URI grants, they will appear in a tab next to Permissions: URI tab

To learn more about URI’s, see Privileges.

Permission Conflicts

Attempting to create a new permission may sometimes generate a conflict warning, as shown here:

Conflict error

You may also see permission conflicts indicated with a red error icon on existing roles:

Conflict on role

A ‘conflict’ means that there are two or more permissions on the same role that contradict each other or are redundant. The reasons that a conflict can occur are:

  • Overlapping scope: Two or more permissions are affecting the same role and data but at different scopes, e.g. one permission grants a role access to a database, and another permission grants this role access to a table within that database. Okera recommends that one of these permissions be deleted.

  • Conflicting access level: Two or more permissions are affecting the same role and data but grant access levels that contradict each other, e.g. one permission grants a role SELECT access to data, and another permission grts this role ALL access to the same data. Okera recommends that one of these permissions be deleted.

  • Conflicting conditions: Two or more permissions are affecting the same role and data but have access conditions that contradict each other, e.g. one permission grants a role access to all data in a table, and another permission only grants this role access to certain tagged data in the same table. Okera recommends that one of these permissions be deleted.

  • Potential conflicting conditions: Two or more permissions are affecting the same role and data, and have access conditions that do not explicitly contradict each other, but should preferably be combined into a single permission, e.g. one permission grants a role access to a table and masks certain tagged data, and another permission grants this role access to the same table and masks different tagged data. Okera recommends consolidating these two permissions into one.

If you attempt to create a new permission and get a conflict warning, you may still create the conflicting permission but this role will be flagged as having conflicts.

When a role has conflicting permissions, the Conflicts column will appear in the Permissions table. Within this column, you can click ‘View Conflicts’ to see conflict details for a given permission. You must edit or delete conflicting permissions to resolve these conflicts.

Making Changes to Permissions

Editing Permissions

Only catalog admins and users with the ability to grant on the relevant data objects can edit permissions.

Click the ‘Edit’ icon at the end of a permission’s row to edit it:

Edit permission button

This will re-open the permissions dialog and allow you to update the permission.

For some permissions, the edit icon may be disabled. This is due to one of the following restrictions:

  • You may not edit permissions on specific data objects if you do not have the ability to grant on that data object.
  • You may not edit permissions with a scope of ‘Column’ because this scope is currently unavailable in the ‘Add permission’ dialog.
  • If you are viewing permissions on the Data page, you may only edit permissions that apply directly to the data object you are viewing. For example, if you are on the Permissions tab of a dataset, you may only edit permissions on that dataset, even though permissions on the catalog or on the relevant database may also appear.
  • You may not edit permissions that have invalid combinations of access conditions, as outlined in the sub-section 'Multiple Access Conditions’ above.

Deleting Permissions

Only catalog admins and users with the ability to grant on the relevant data objects can delete permissions.

Click the ‘Delete’ icon at the end of a permission’s row to delete it:

Delete permission button

This will revoke any access granted by this permission from the role.