Concepts
Deep Dive Tutorials
1. Model Your Application’s Authorization

1. Model Your Application’s Authorization

hr-app-diagram.png

Before diving into writing your authorization in a policy, you’ll want to have a clear picture of the application and its parts. As depicted in the diagram above, the human resources app hosts many organizations. Each organization has its own set of users and those users have one of two roles: admin or employee. Users of this application have the ability to perform actions based on their role, but **only** within their organization. Our authorization policy should exist to enforce this view of the world.

In this section you will:

Putting the Building Blocks in Place

To begin building the policy, answer the following questions:

  1. Who uses the application? (Users within an organization).
  2. What resources make up the application? (Organizations).
  3. What actions require authorization before a user can perform them? (Getting an admin view and getting an employee view of the application).
  4. How are permissions granted within the application? (Through roles).
  5. How are permissions attached to roles? (Through logic rules).

Now, all that’s left to do is write what we know in Polar!


# 1. Who uses the application?
# Users are the actors *who* use the application.
# Users perform actions within an Organization,
# as defined in the resource block below.
actor User {}
# 2. What resources that make up the application?
# Organizations are modeled by this resource block.
# Organizations are *what* Users interact with in
# the application.
resource Organization {
# 3. What actions require authorization?
# Permissions represent the actions Users can
# perform within an Organization.
permissions = [
"admin_view",
"employee_view"
];
# 4. How are permissions granted within the application?
# Roles represent identities Users within
# Organizations may have.
roles = [
"admin",
"employee"
];
# 5. How are permissions attached to roles?
# The combination of roles and permissions are one
# way to define authorization for a resource.
# The rules below grant permissions to specific
# roles as determined by your application's needs.
"employee_view" if "employee";
"admin_view" if "admin";
}

Action Items

The next step is to add some authorization data.

Additional Resources

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 →