Skip to content

Grant Data Access Using Permissions

Now that you’ve explored the Okera catalog, let’s grant access to the data using permissions.

We'll explore the access conditions already in place that may be affecting your new sales director, danny_<tenant> and your two sales analysts, sam_<tenant> and sally_<tenant>. We will then use several types of access conditions to protect the data.

Simulate the End User Experience

Embedded links for Apache Superset, JupyterHub, and Snowflake on the Home page of Okera allow you to access these applications and simulate what different users see when they access data through Okera. Simply log in to these applications using the same login credentials provided in your test drive email.

Several preconfigured dashboards are provided in Apache Superset; however, you can create new dashboards based on the data in this test drive environment if you would like to test different views or simulate how users might query data. You can also manage dashboards and the users with access to the dashboards by logging into Superset as the admin_<tenant> user.

  1. Navigate to Apache Superset using the Open Superset link on the Okera Home page or the link provided in the test drive email.

  2. Log in as the admin_<tenant> user using the password provided in the test drive email and select Dashboards at the top of the Superset page to navigate to the Superset Dashboards page. The image below shows the dashboard view after logging in as admin_<tenant>.

    Admin Superset View

  3. Select the dashboard called Okera Demo Dashboard.Sales to view and interact with the data.

    Admin Superset Sales View

  4. Browse other dashboards and log in as other users you may be interested in.

    Note: When a user does not have access to a dashboard in Apache Superset, errors appear on the dashboard instead of actual data:

    Superset no access errors

  5. Return to your Okera test drive cluster.

Review the Provided Permissions

To review the permissions provided with your Okera test drive:

  1. Log in to Okera as the admin_<tenant> user. The password is provided in your test drive email.

  2. Select Data in the left-hand menu to access the Data page.

  3. Select the sales database and then select the Permissions tab. Only users who are allowed to manage permissions, such as the admin_<tenant> user, can see this tab. If you don't see it, make sure you are logged in as admin_<tenant>.

    Sales database permissions

    Two roles have been granted access to the sales database. Users assigned these roles can access it:

    • Users assigned the admin_role are granted ALL access across the catalog, which gives them unrestricted access to all data.
    • Users assigned the sales_analyst_role can view the data, but data that is restricted is masked.

Note: Because these permissions have been granted at the database level, they apply to all datasets (tables) included in the sales database.

Review the Safeguard Policies

When you select the Permissions tab for a database, a banner displays that reads “Safeguard policies may affect permissions on this database.Safeguard policies apply at the catalog-level and are automatically applied after access has been granted to a user through a permission.

Select Show safeguard policies to see the safeguard policies present in this test drive environment.

Two safeguard policies, Mask Restricted Data and Mask SSN are supplied to protect data across the catalog. These policies impact how the data appears for users within your organization after they are granted access to the database. These policies mask any data considered restricted (classified as classification.restricted) and social security numbers (classified as pii.us_ssn).

Grant Access for Sales Directors

The sales_director_role is currently not granted access to the sales database because it is a new role. Let's grant it access. Complete the following steps.

Note: At the end of this section, a video of these steps is provided.

  1. Log in to Apache Superset as the sales director danny_<tenant>, using his unique password provided in the test drive email.

  2. Navigate to the Sales dashboard in Apache Superset (select Dashboards at the top of the Superset page and then select Okera Demo Dashboard.Sales). You can see that because danny_<tenant> does not have access to the sales database, his dashboard view shows Presto errors.

  3. Log in to Okera as admin_<tenant>.

  4. Select Roles on the left-hand menu to navigate to the Roles page. Locate and select the role called sales_director_role, used for territory directors for the sales organization (such as danny_<tenant>). We want to grant users assigned this role access, while ensuring that they can only see data pertaining to the territory they manage.

    Okera Roles Page

  5. Select to open the permission builder dialog.

  6. Leave the Scope selection set to Database but select the sales database from the Database dropdown list.

  7. Leave the Access level set to SELECT.

  8. Select Add an access condition. The Access conditions section expands.

  9. Select Restrict access with row filtering from the Condition dropdown list and Column from the "Only grant access to data WHERE..." dropdown list.

  10. In the Column text box, type region. Select the matches user attribute operator from the Operator dropdown list. Finally, select territory in the User attribute key dropdown list. If territory does not exist in the User attribute key list, type it in and then select Create "territory" underneath the list.

    Sales director policy builder

    The dialog should look like this:

    Sales director policy builder

  11. Select . The “Permission added” confirmation dialog appears. (Select OK on this dialog.)

  12. Validate the new sales_director_role permission by returning to Apache Superset, logging in as the user danny_<tenant>, viewing the Okera Demo Dashboard.Sales dashboard. Confirm that danny_<tenant> can now see data, but only for North America. You might need to reload (refresh) the page.

Images

Danny (sales director) does not have access to data.

Danny (sales director) sees data, but only for his territory, North America.

Here is a video of the steps above.

Limit Access for Sales Analysts by Region

To understand how sales analysts, such as sam_<tenant> or sally_<tenant>, might currently view data in the sales database, let's investigate their views in Apache Superset and then alter their access to limit it by the region or country to which they are assigned. Complete the following steps.

Note: At the end of this section, a video of these steps is provided.

  1. Log in to Apache Superset as sally_<tenant>. The password for sally_<tenant> is provided in your test drive email.

  2. Open the Okera Demo Dashboard.Sales dashboard. You can see that while sensitive data is masked, she can still see data pertaining to all regions and countries.

  3. Log in to Okera as admin_<tenant>, select Data from the left-hand menu and then select the sales database from the list.

  4. Select the Permissions tab for the sales database.

    Edit sales analyst access condition

  5. Select the edit icon () next to the permission at the end of the row for the sales_analyst_role. This opens the permission builder dialog, which is where you can grant access and create permissions that enforce fine-grained access control.

  6. In the permission dialog, select Add another access condition to add another access condition.

  7. Select “Restrict access with row filtering” from the Condition dropdown list and Column in the "Only grant access to data WHERE..." dropdown list.

  8. Type country in the Column textbox, select the matches user attribute operator from the Operator dropdown list, and select country from the User attribute key dropdown list, as shown in the screenshot below. If country does not exist in the User attribute key list, type it in and then select Create "country" underneath the list.

    Note: The matches user attribute operator guarantees that if a user is responsible for multiple countries, then they are granted access to see all their countries. To learn about creating permissions with row filtering conditions, read Create Row-Level Security Permissions.

    Okera Policy Builder country condition

  9. Select . The Permission added dialog appears confirming the update. (Select OK on this dialog.)

  10. Validate that the permission has been applied correctly by logging into Apache Superset as sally_<tenant> again and navigating to the Okera Demo Dashboard.Sales dashboard. You can see that she only sees data from the United States.

    Log out of Superset and log in again as sam_<tenant>, using the password supplied in your test drive email. When you access the Okera Demo Dashboard. Sales dashboard again, you can see that Sam only sees data from France (which is the country to which he is assigned).

    You can see which country a user is assigned in the Okera UI using the User Attributes list on the Users page after selecting the user.

Images

Sally sees all countries.

Sally only sees countries she is assigned.

Here is a video of the steps above.

Limit Sales Analyst Access to PII

Use tags in Okera to designate whether a field contains personally identifiable information (PII) and the type of PII data that is reflected. To ensure that the sales analysts, sally_<tenant> and sam_<tenant>, do not have access to sensitive customer data, let's review the tags that are available, apply them, and create a new access condition that restricts the sales analyst view.

Tags are attributes that can be applied to data. Attributes provide a powerful abstraction over physical metadata such as table and column names, allowing for more general policy definitions that are easier to maintain.

Note: At the end of this section, a video of these steps is provided.

  1. Log in to Okera as admin_<tenant>.

  2. Select Tags from the left-hand menu to access the Tags page and review the current tags in the test drive environment.

    Tags are grouped by namespaces so if you are working with a specific domain (such as sales), the corresponding tags are representative of the data in that business unit. Okera provides an out-of-the-box pii namespace.

    Tags Page

  3. Select Data and navigate to the sales database.

  4. Select the customer_contact_details dataset in the sales database. This opens the data schema, which is where tags and other additional information can be applied, as shown in the image below.

    Customer Contact Details Schema

    As you can see, several columns in the customer_contact_details table include customer personally identifiable information (PII), however, they have not been tagged.

  5. Select for each of the following columns: contactname, email, phone, and address. For each column, select the corresponding tag within the pii namespace, as shown in the following table and in the image below.

    Column Name Use This Tag
    contactname pii: name
    email pii: email_address
    phone pii: phone_number
    address pii: address

    Tags added to Customer Schema

  6. After your tags have been added to the customer_contact_details schema, navigate back to the sales database.

  7. Select the Permissions tab and select the edit icon () next to the sales_analyst_role.

  8. Select Add another access condition and then select Transform data from the Condition dropdown list.

  9. In the Tags box, select each of the pii.* tags that you previously added to the data schema: pii:name, pii:email_address, pii:phone_number, and pii:address.

  10. Select "Mask" from the Transform type dropdown list. The access conditions for the permission should look like this:

    PII masking condition

  11. Select . The Permission added dialog appears confirming the update. (Select OK on this dialog.)

  12. Open Superset, log in as the sales analyst sally_<tenant>, and refresh the Okera Demo Dashboard.Sales dashboard. If the personally identifying data in the Customer chart is now masked, the access condition has been applied successfully.

Images

Sally sees PII customer data.

Sally does not see PII data.

Here is a video of the steps above.

Next Step

Add and register new data in Okera.