4. Monitor and Debug Your Authorization

In this section you will:

Use the Logs page (opens in a new tab) to monitor your recent authorization checks.
Use the Explain page (opens in a new tab) to investigate authorization checks that may have an unexpected result.
Navigate through Pass/Fail attempts on the Explain page.
Use information from the Explain page to make improvements to your policy.

Additional Resources

Learn about the Explain page and its layout

Authorization Check logs

Oso Cloud logs all Oso client Query and Check API calls. You can use the Logs page (opens in a new tab) to see the most recent client activity from any of your applications using the Oso client. If you have been following along with this tutorial, your Logs page might look something like this:

Each of the authorize commands that you ran using the Oso Cloud CLI are now logged and visible in the Dashboard for up to 24 hours. The Logs page gives you a brief summary of the authorization check that was made, when it was made, and its result. This enables you to gain insight into your app's usage of Oso Cloud, even if you are not the one making the authorization checks directly.

Should you have any questions about a particular result, you can click the "Try this query" button. It will bring you to the Explain page where you'll be presented with information to better understand the authorization result.

NOTE: The "Try this query" button will only appear for allow queries. When you use the authorize command in > Oso Cloud clients, it will appear as an allow query on the Logs page (opens in a new tab).

Action Items

Click the "Try this query" button to examine the logic behind one of the authorization results shown.

Using Explain to Debug Your Authorization

Now suppose at some point in time User:paula decides to use the employee_view on Organization:org_1 where they are an admin. However, they report that they are unable to access the employee_view. You can use the Explain page (opens in a new tab) to examine the logic regarding the user's permission to access the employee_view.

Go the Explain page (opens in a new tab) and run the authorization check below.


User:paula "employee_view" Organization:org_1

Explain will display two failed attempts.

Remember, Paula was assigned an admin role in Add Authorization data to Oso Cloud. Given the current policy, this authorization attempt does not give the admin Paula, the ability to see an employee view of the organization Org 1. Should this be the case?

Action Items

Click on each attempt to see what information Oso Cloud used to make its decision.

Option 1

The first attempt shows you that if user Paula is given the employee_view permission explicitly, then our authorization attempt would succeed. Adding the fact:

has_permission (User:paula, "employee_view", Organization:org_1) would allow the authorization attempt to succeed. However, one consideration to make is that it requires adding a permission as a fact rather than a role. So far, all of the authorization data given to Oso Cloud has been based on roles, not permissions.

Option 2

Another option comes from the second attempt.

You could add another role for the user Paula. In this case, two facts would exist:

One stating that Paula is an admin - Another stating that Paula is an employee

While admins may also be employees, it's also conceivable that in some cases admins are distinct from employees and should not be modeled that way. In general it can lead to confusion.

Option 3

But, there exists a third option! If it does not make sense to add the facts presented in the attempts, this suggests that the initial authorization model (developed in Model Your Application’s Authorization) could be improved.

The policy has the following rules within the Organization resource block:


resource Organization {
    ...
    "employee_view" if "employee";
    "admin_view" if "admin";
}

If admins should also have the ability to see an employee view of an organization, then it can be modeled by adding the employee_view permission to admin roles.

With simple authorization rules, it's not hard to keep in mind the various combinations. But, as policies become more complex, seeing the various permutations of facts needed for successful authorization attempts can bare to light bugs or shortcomings in your policy.

Updating Your Policy

Add the following rule to your existing Organization resource block.


"employee_view" if "admin";

Your resulting policy will look like this:


actor User {}
resource Organization {
    permissions = [
        "admin_view",
        "employee_view"
    ];
    roles = [
        "admin",
        "employee"
    ];
    # Rules granting permissions to the employee role.
    "employee_view" if "employee";
    # Rules granting permissions to the admin role.
    "admin_view" if "admin";
    "employee_view" if "admin"
}

Action Items

Update your existing policy with the new version above.

Re-run the authorization check using the Explain page:
User:paula "employee_view" Organization:org_1

After updating your existing policy with this new version, you will observe that Oso Cloud now recognizes the user Paula has both permissions: employee_view and admin_view.

Talk to an Oso Engineer

If you'd like to learn more about using Oso Cloud in your app or have any questions about this guide, connect with us on Slack. We're happy to help.

Get started with Oso Cloud →

Summary