Skip to content

Granting permissions

Now that you’ve explored the Okera catalog, let’s dive into granting access to data via permissions.

In this section, you will learn what access conditions may already be in place affecting your new sales director, danny and your two sales analysts, sam and sally. You will then be introduced to several types of access conditions, which will help protect your data.

  1. As the admin user, navigate to the Users page. Here you can see all the users who have accessed data through Okera, as well as their identity information including groups and Okera roles.
Okera Sales Tutorial Users

Understanding downstream users' view

For this tutorial, we have embedded links in the homepage for you to simulate what it is like to view data for different users. In order to login and see a certain user's view, simply login with this user's credentials provided in the introduction email. There are several dashboard preconfigured in Superset, however, you are also able to create new dashboards based on the data in this trial environment if you would like to test different views or simulate how users might query data. You also have the option to manage dashboards and which users have access by logging into Superset as the admin user. The dashboard below shows the dashboard view after logging in as an admin.

  1. Navigate to Superset via Okera Homepage or the link provided in the intro kit that was emailed to you.

  2. Login as your admin user with the password provided in the intro kit and navigate to the dashboards page.

    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 login as other users you may be interested in.

    Note

    When a user does not have access to a dashboard in Superset, there will be errors on the dashboard in place of actual data.

    Superset no access errors

  5. Return to your Okera trial cluster.

Understanding Permissions

Now it’s time to see how you can view, create and edit permissions in Okera.

  1. Click on the Data page
  2. Navigate to the sales database and click the Permissions tab. Only users who have access to manage permissions can see this tab, and in this case you are the admin user.

    Sales database permissions

    There are already two permissions in place which grant access to users with the following roles:

    • Admin-role is granted all access across the catalog, which gives them unrestricted access
    • Users in the sales-analyst-role can view the data but data that is restricted or PII will be masked

Note that because these permissions have been granted at the database scope, they will apply to all tables inside the sales database.

Understanding Safeguard Policies

When you view the permissions tab you will notice a banner letting you know that “safeguard policies may affect permissions on this database”. Safeguard policies apply at the catalog level and will automatically apply once access has been granted to a given user through a permission.

  1. Click “show safeguard policies” to see the safeguard policies that are already present in this trial environment.

    Safeguard policies

The compliance oficer at your company has created two safeguard policies to protect data across the catalog, which will impact data for users within your organization once they are granted access to data that this policy applies to. All data across the catalog that is considered restricted and data social security numbers will be masked.

Granting Access to Sales Directors

As you can see, the sales_director_role is currently not granted access to the Sales database since it is a new role.

  1. Return to your Superset dashboard and login as the sales director, danny using his unique password provided in the intro kit.
  2. Navigate to the sales dashboard and you will see that since danny does not have access, his dashboard view is errored out.
  3. Navigate to the roles page in Okera and you can see that there is a role called sales_director_role, which for this example refers to territory directors for the sales organization like danny. We want to grant them access while ensuring that they can only see data pertaining to the territory that they manage.

    Okera Roles Page

    You can grant access to users with the sales_director_role directly from the roles page by pressing “Create new permission” and it will open the policy builder. For this example we’re going to grant access to the sales_director_role and include a condition with row filtering.

  4. Select the sales from the database dropdown and add an access condition.

  5. Press "Add Acess Condition" and choose “Restrict access with row filtering” from the Condition dropdown and column from as the condition type. Next type region in the column textbox, select the operator “matches user attribute,” and choose the user attribute territory from the dropdown as shown below and click “Add permission”. You will see the “Permission added” confirmation dialog.
    In this case, we want to specify region as the column name and territory for the user attribute as shown below.
    
Sales director policy builder

Validate the new sales_director_role permission by returning to Superset and logging in as the user danny to confirm that he can now only see data for NA.

Condition

Director does not have access to data

Director only sees data for their territory

Redefining Sales Analysts' Access

Since we want to understand how the sales analysts, such as sam or sally, might currently view data in the Sales database, we're going to investitage their views in Superset.

  1. Navigate back to Superset and login as sally.

  2. Open the Sales dashboard and you will see that while sensitive data is masked she can still see data pertaining to all regions and countries.

  3. Return to Okera and navigate back to the Sales database.

  4. Navigate to the Permissions tab in the sales database and press the edit icon next to the permission for the sales_analyst_role. This will open the policy builder, which is where you can grant access and create permissions that enforce fine-grained access control.

    Edit sales analyst access condition

  5. In the policy builder, press “Add an access condition."

  6. Select “Restrict access with row filtering” from the Condition dropdown and column from the type drop down. Next type ‘country’ in the column textbox, select the operator “matches user attribute,” and choose the user attribute country from the dropdown as shown below.

    Note

    The matches user attributes operator guarantees that if a user is responsible for multiple countries then they will be granted access to see all of their countries. To learn more about creating permissions with row filtering conditions please read more here.

Okera Policy Builder country condition

After you add the permission, you can validate that it is applied correctly by navigating to the Superset dashboard and logging in as one of the analyst users. This will enable you to see that they can only see data pertaining to their country that is shown under each user on the users page.

Condition

Analyst sees all countries

Analyst only sees their country

Understanding Safeguard Policies

When viewing permissions you will notice a banner letting you know that “safeguard policies may affect permissions on this database”. Safeguard policies apply at the catalog level and will automatically apply once access has been granted to a given user through a permission.

  1. Click “show safeguard policies” to see the safeguard policies that are already present in this trial environment.

    Safeguard policies

The compliance officer in your organization has created two safeguard policies, which will impact data for users who have been granted access to this table. All data across the catalog that is considered restricted and social security numbers will be masked.

Limiting Sales Analysts' access to PII

In Okera we use tags to designate whether or not it is PII and what types of PII data are reflected. To ensure that the sales analysts, sally and sam, do not have access to customer data that is PII, we will review what tags are available, apply these tags, and create a new access condition that restricts their view.

Note

Tags are a form of attribute that can be applied on the data. Attributes provide a powerful abstraction over physical metadata such as table and column names, which enables defining policies that are more general and easier to maintain.

  1. To review the current tags we’ve pre-created in this trial environment, navigate to the Tags page in the Okera UI.

    Tags are grouped by namespaces so if you have a specific domain you’re working with such as sales, the corresponding tags can be representative of the data your business unit is interacting with. Okera provides an out-of-the-box PII namespace.

    Tags Page

  2. Navigate to the sales database.

  3. On the sales database, click the customer_contact_details dataset. This will open up the data schema, which includes where tags can be applied and other additional information as shown in the image below.

    Customer Contact Details Schema

    As you can see several columns in the customer_contact_details table include customer pii information, however, they have not been tagged.

  4. Next, click "Add tag" for the columns: contactname, email, phone, and address. For each column, add the corresponding tag within the PII namespace shown in the image below.

    Tags added to Customer Schema

    Note

    In order to apply the tag, be sure to click the checkmark once you are done adding relevant tags.

    Properly add tags

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

  6. Go to the Permissions tab and click the edit icon next to the sales_analyst_role permission.

  7. Press "Add another access condition" and select "Transform data" from the Condition dropdown.

  8. In the tags box, select the PII tags that you previously added to the data schema: name, email_address, phone_number, and address.

    PII masking condition

  9. Select "Mask" from the Transform type dropdown and press "Update Permission."

  10. Open Superset, login as the sales analyst, sally, and refresh the Sales dashboard. You will see that the personally identifying data in the Customer chart is now masked and the access condition has been applied successfully.

Condition

Analyst sees PII customer data

Analyst does not see PII data

Next Step

Learn how to add new data