Authorization Policy

FREE

By Styra, Inc | Updated hace un mes | Tools

Health Check

N/A

README

The Authorization Policy API provides Authorization as a Service (ZaaS) to let you write declarative policies that decide who can do what within your application. It runs the Open Policy Agent (OPA) internally and lets you write policies in the OPA language. It is a general-purpose policy API, meaning that you can use it to solve a wide range of authorization (and non-authorization) policy problems.

Use Cases

With the OPA ZaaS you can write policies that decide which users can execute which tasks or which database columns users can see. The tutorials demonstrate how to carry out each of those use cases.

Authorization Models
Traditionally, authorization falls into one of two camps: RBAC or ABAC. OPA’s ZaaS lets you use either of those models, and it lets you invent your own.

RBAC (role-based access control). Here you define a mapping from users (e.g. alice) to roles (e.g. engineer) and a separate mapping from roles (e.g. engineering) to permissions (e.g. read). A user is granted all permissions granted to the roles that user is assigned to. If alice is assigned the role engineering and engineering is assigned read and write, then alice is assigned read and write.

ABAC (attribute-based access control). Here you define a mapping from users to attributes and then define which collection of attributes is required for each permission. alice might have attributes job: engineer and startdate: 01/01/2017. admin rights might require being an engineer with at least 3 years of experience.

Context Awareness
One question that comes up is what kind of information you can use when writing your policies. You might need information about users, the time of day, or from some third-party service like the current weather conditions. The good news is that OPA ZaaS lets you inject whatever information you need and write conditions in your policy based on that information, e.g. “if the weather in the user’s location is below freezing, don’t authorize her to turn on the air conditioning”.

The tutorials show you how to inject external context either from 3rd parties or from your own application. You can also check out the builtins in the OPA language for authoring policy (including time-of-day).

Simple Integration
Integrating your application with OPA ZaaS usually requires adding just a few simple HTTP calls. {{book.sysname}} provides a RESTful API for:

CRUD (create-read-update-delete) on policies
CRUD on context/data
queries for policy decisions

RBAC

Application developers often need to expose RBAC (Role-Based Access Control)
so that admins of the application can control who can do what within that
application. TENANT.styra.com can be used as the backend implementation of
RBAC (RBAC-as-a-service), obviating the need for the application developer
to build the RBAC implementation (storage, query, API).

Goals

This tutorial is aimed at an application developer who needs to implement
an RBAC solution for her application. Instead of rolling her own RBAC
implementation, you (the application developer) will integrate your application
with TENANT.styra.com so it provides all authorization decisions.

Prerequisites

This tutorial requires only that you have an account at TENANT.styra.com and
that you have an application that can send HTTPS requests to TENANT.styra.com.

Overview

In this tutorial, we will assume you are writing a financial application that
lets users:

Read, buy, and sell stocks and bonds
Change which users are assigned which roles
You will use TENANT.styra.com to create an RBAC system that controls who can perform the actions listed above.

You will do two things:

Configure TENANT.styra.com
- Create a datasource that stores (and lets your application update) User-Role assignments
- Write a policy that decides whether a given user has a given permission (by checking if the given user is assigned a role that has the given permission).
Integrate your application with TENANT.styra.com
- Modify your application to push User-Role assignments to TENANT.styra.com whenever they change
- Modify your application to ask for authorization decisions from TENANT.styra.com before performing any critical task

Configuration

1. Create a Datasource to record User-to-Role assignments

Your application needs to store user-to-role assignments somewhere, and
it needs to update them whenever an admin chooses to do so. So configure
TENANT.styra.com to store user-to-role assignments as a JSON document and
open an API that your application can push those assignments to.

Create a datasource that lets you assign users to roles.

Go to TENANT.styra.com > Datasources > Add
Choose Custom datasource
Enter the following fields

Pathname: rbac/user_roles

Click Finish

Now your application will be able to store your user-to-role assignments
by making a RESTful API call to https://TENANT.styra.com/v1/data/rbac/user_roles.

2. Create Authorization Policy

Next you’ll write a policy that takes as input a username and the name of a task
and decides whether that username is authorized to perform that task.

Go to TENANT.styra.com > Policies > Add and copy-paste the following text into the editor. Then click the Publish icon (an up-arrow) in the upper-right corner of the editor.

package rbac.authz
import data.rbac.user_roles

# Define groups of permissions
read_permissions = {"read_stock", "read_bond"}
trader_permissions = {"buy_stock", "sell_stock", "buy_bond", "sell_bond"}
rbac_permissions = {"read_rbac", "modify_rbac"}

# Assign roles to sets of permissions
role_permissions["normal"] = read_permissions {
    true
}
role_permissions["trader"] = x {
    x = read_permissions | trader_permissions
}
role_permissions["admin"] = x {
    x1 = read_permissions | trader_permissions
    x = x1 | rbac_permissions
}

# Authorization logic
default allow = false
allow {
    roles = user_roles[input.user]       # Lookup roles for user
    role = roles[_]                      # Iterate over all roles
    permissions = role_permissions[role] # Lookup permission list for role
    permissions[_] = input.permission    # Check if requested perm in permission list
}

Integration

Now that you’ve configured TENANT.styra.com, you will integrate your
application to use TENANT.styra.com. The integration requires that
you make RESTful HTTPS calls to TENANT.styra.com. Here we show
which calls you make with curl commands so that you can try out
the tutorial without actually modifying your application.

1. Create a Service Account for TENANT.styra.com

Your application needs a service-account token to talk to TENANT.styra.com,
so create one.

Go to TENANT.styra.com > ☰ > API Tokens
Click “Add API Token” at the bottom of the dialog and enter the following settings
- Pathname: enter a name you haven’t used for a service account.
Click OK
Copy the Secret (you won’t be able to retrieve it after this step)
Click Done

2. Integrate Application to Retrieve/Update User-Role assignments

Your application lets an administrator control which users are assigned
which roles within your application. You will integrate your application
to both read and write the user-role assignments from the datasource
you configured on TENANT.styra.com earlier.

Every time the admin uses your application to set the user-role
assignments, your application stores the new assignments at TENANT.styra.com.

curl -X PUT 'https://dogfood.styra.com/v1/data/rbac/user_roles' \
     -d '{"alice": ["normal"], "bob": ["trader"], "charlie": ["admin"]}' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -H "Content-type: application/json"

Every time the admin asks to see the current user-role assignments,
your application retrieves them from TENANT.styra.com/v1/data/rbac/user_roles.

curl 'https://dogfood.styra.com/v1/data/rbac/user_roles' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>"

{
  "alice": ["normal"], 
  "bob": ["trader"], 
  "charlie": ["admin"]
}

3. Integrate Application to ask for Authorization decisions

Before your application performs a task like read/buy/sell stocks/bonds or
read/modify user-to-role assignments, it needs to check if the user performing
the task is authorized to do so. The authorization check provides as input
the username and the task being performed and results in a true/false (allow/deny) decision.

For example, if alice is trying to perform the task read_stock, then
TENANT.styra.com will return true when your application makes
the following API call. (Semantically the API call is a GET,
but is implemented as a POST to provide input data in the body.)

POST https://dogfood.styra.com/v1/data/rbac/authz/allow

{"input": {"user": "alice", "permission": "read_stock"}}

curl -X POST "https://dogfood.styra.com/v1/data/rbac/authz/allow" \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": {"user": "alice", "permission": "read_stock"}}'

{"result":true}

But if alice tries to buy_stock, she is denied.

curl -X POST "https://dogfood.styra.com/v1/data/rbac/authz/allow" \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": {"user": "alice", "permission": "buy_stock"}}'

{"result":false}

Wrap Up

Congratulations on finishing the tutorial!

You learned how to use TENANT.styra.com to implement authorization for your
application. In particular, you learned:

How to write RBAC in the policy language supported by TENANT.styra.com
How to store/update JSON data that your policy depends on
How to integrate your application with a couple of RESTful API calls into TENANT.styra.com

Database Columns

Application developers often need to know what fields from a database
table a user is authorized to see. Often that information gets hardcoded
into the application, making it difficult to modify, analyze,
and collaborate on.

TENANT.styra.com lets the application developer write her application
to ask for the authorized database columns through an API. It also
gives application developers, security professionals, and compliance
officers a centralized place to write and analyze the policy
that decides which users should see which database columns.

Goals

This tutorial shows an application developer how to decouple the
decision about which database columns a user is allowed to see
from the application that helps the user interact with that data.
You (the application developer) will integrate your application
to use TENANT.styra.com’s API to discover which database columns
the current user is allowed to see.

Prerequisites

This tutorial requires only that you have an account at TENANT.styra.com and
that you have an application that can send HTTPS requests to TENANT.styra.com.

Overview

In this tutorial, we assume you are writing an application that displays
detailed information about employees in your organization. You need
to decide which columns in the database to show depending on who
is logged in and whose information you are trying to see.

In particular, your application uses the following data.

First name
Last name
Address
Phone number
Social security number

You will do two main things:

Write a policy that decides which of the database columns shown
above are authorized for the current user.
Modify your application to ask which columns the current user is
authorized for.

1. Create a Policy on TENANT.styra.com

The policy you are about to write takes as input:

the user requesting information
the employee whose information is being requested

For simplicity, we are hard-coding user-data into the policy,
but you can use TENANT.styra.com to import that data from LDAP
or ActiveDirectory.

Go to TENANT.styra.com > Policies > Add and copy-paste the following text into the editor. Then click the Publish icon (an up-arrow) in the upper-right corner of the editor.

package columns

# deny SSN to anyone other than the user and HR
deny["ssn"] {
   input.user != input.employee
   not is_hr(input.user)
}

# deny phone number to general public
deny["phone"] {
   input.user = ""      
}

is_hr(user) {
  employees[user].roles[_] = "hr"
}

# Could be imported from LDAP/AD, instead of hard-coded in policy.
# If imported from LDAP/AD, format would be different, which
#   would require is_hr function to change
employees = {
    "bob": {"manager": "janet", "roles": ["engineering"]},
    "alice": {"manager": "janet", "roles": ["engineering"]},
    "janet": {"roles": ["engineering"]},
    "ken": {"roles": ["hr"]},
}

2. Create a Service Account for TENANT.styra.com

Your application needs a service-account to talk to TENANT.styra.com,
so create one.

Go to TENANT.styra.com > ☰ > API Tokens
Click “Add API Token” at the bottom of the dialog and enter the following settings
- Pathname: enter a name you haven’t used for a service account.
Click OK
Copy the Secret (you won’t be able to retrieve it after this step)
Click Done

3. Integrate Application to ask for Database Column Decisions

Every time a user asks for employee data, your application will
make an API call to TENANT.styra.com to ask for the database
columns the user is authorized to see.

Every time the admin asks to see the current user-role assignments,
your application retrieves them from TENANT.styra.com/v1/data/columns/deny.

Below you use the token you just generated to ask about the database
columns when alice asks for bob's employee information. In this case
alice is prohibited from seeing the ssh column.

curl -X POST 'https://dogfood.styra.com/v1/data/columns/deny' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": "user": "alice", "employee": "bob"}'

["ssn"]

An unauthenticated user asks for bob's employee information. She is
prohibited from seeing the ssh and phone columns.

curl -X POST 'https://dogfood.styra.com/v1/data/columns/deny' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": "user": "", "employee": "bob"}'

["ssn", "phone"]

Once the application knows which columns to skip, it can remove those
from the database query it runs.

Wrap Up

Congratulations on finishing the tutorial!

You learned how to use TENANT.styra.com to add policy-based control
to which database columns your users see.
In particular, you learned

How to write policy that decides which database columns to
hide from the user.
How to integrate your application with TENANT.styra.com’s
RESTful API

While the tutorial was aimed at databases, the same setup works
for any kind of service where your application controls which
fields are shown to the user.

Sign up here
Follow the link sent to your email to activate your account
Enter the email and password to activate your account
Wait for an email which will contain a link to your developer environment. And happy authorization!
Sign up here
Follow the link sent to your email to activate your account
Enter the email and password to activate your account
Wait for an email which will contain a link to your developer environment. And happy authorization!

RBAC

Goals

Prerequisites

This tutorial requires only that you have an account at TENANT.styra.com and
that you have an application that can send HTTPS requests to TENANT.styra.com.

Overview

In this tutorial, we will assume you are writing a financial application that
lets users:

Read, buy, and sell stocks and bonds
Change which users are assigned which roles
You will use TENANT.styra.com to create an RBAC system that controls who can perform the actions listed above.

You will do two things:

Configure TENANT.styra.com
- Create a datasource that stores (and lets your application update) User-Role assignments
- Write a policy that decides whether a given user has a given permission (by checking if the given user is assigned a role that has the given permission).
Integrate your application with TENANT.styra.com
- Modify your application to push User-Role assignments to TENANT.styra.com whenever they change
- Modify your application to ask for authorization decisions from TENANT.styra.com before performing any critical task

Configuration

1. Create a Datasource to record User-to-Role assignments

Create a datasource that lets you assign users to roles.

Go to TENANT.styra.com > Datasources > Add
Choose Custom datasource
Enter the following fields

Pathname: rbac/user_roles

Click Finish

Now your application will be able to store your user-to-role assignments
by making a RESTful API call to https://TENANT.styra.com/v1/data/rbac/user_roles.

2. Create Authorization Policy

Next you’ll write a policy that takes as input a username and the name of a task
and decides whether that username is authorized to perform that task.

Go to TENANT.styra.com > Policies > Add and copy-paste the following text into the editor. Then click the Publish icon (an up-arrow) in the upper-right corner of the editor.

package rbac.authz
import data.rbac.user_roles

# Define groups of permissions
read_permissions = {"read_stock", "read_bond"}
trader_permissions = {"buy_stock", "sell_stock", "buy_bond", "sell_bond"}
rbac_permissions = {"read_rbac", "modify_rbac"}

# Assign roles to sets of permissions
role_permissions["normal"] = read_permissions {
    true
}
role_permissions["trader"] = x {
    x = read_permissions | trader_permissions
}
role_permissions["admin"] = x {
    x1 = read_permissions | trader_permissions
    x = x1 | rbac_permissions
}

# Authorization logic
default allow = false
allow {
    roles = user_roles[input.user]       # Lookup roles for user
    role = roles[_]                      # Iterate over all roles
    permissions = role_permissions[role] # Lookup permission list for role
    permissions[_] = input.permission    # Check if requested perm in permission list
}

Integration

1. Create a Service Account for TENANT.styra.com

Your application needs a service-account token to talk to TENANT.styra.com,
so create one.

Go to TENANT.styra.com > ☰ > API Tokens
Click “Add API Token” at the bottom of the dialog and enter the following settings
- Pathname: enter a name you haven’t used for a service account.
Click OK
Copy the Secret (you won’t be able to retrieve it after this step)
Click Done

2. Integrate Application to Retrieve/Update User-Role assignments

Every time the admin uses your application to set the user-role
assignments, your application stores the new assignments at TENANT.styra.com.

curl -X PUT 'https://<TENANT>.styra.com/v1/data/rbac/user_roles' \
     -d '{"alice": ["normal"], "bob": ["trader"], "charlie": ["admin"]}' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -H "Content-type: application/json"

Every time the admin asks to see the current user-role assignments,
your application retrieves them from TENANT.styra.com/v1/data/rbac/user_roles.

curl 'https://<TENANT>.styra.com/v1/data/rbac/user_roles' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>"

{
  "alice": ["normal"], 
  "bob": ["trader"], 
  "charlie": ["admin"]
}

3. Integrate Application to ask for Authorization decisions

POST https://dogfood.styra.com/v1/data/rbac/authz/allow

{"input": {"user": "alice", "permission": "read_stock"}}

curl -X POST "https://<TENANT>.styra.com/v1/data/rbac/authz/allow" \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": {"user": "alice", "permission": "read_stock"}}'

{"result":true}

But if alice tries to buy_stock, she is denied.

curl -X POST "https://<TENANT>.styra.com/v1/data/rbac/authz/allow" \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": {"user": "alice", "permission": "buy_stock"}}'

{"result":false}

Wrap Up

Congratulations on finishing the tutorial!

You learned how to use TENANT.styra.com to implement authorization for your
application. In particular, you learned:

How to write RBAC in the policy language supported by TENANT.styra.com
How to store/update JSON data that your policy depends on
How to integrate your application with a couple of RESTful API calls into TENANT.styra.com

Database Columns

Goals

Prerequisites

This tutorial requires only that you have an account at TENANT.styra.com and
that you have an application that can send HTTPS requests to TENANT.styra.com.

Overview

In particular, your application uses the following data.

First name
Last name
Address
Phone number
Social security number

You will do two main things:

Write a policy that decides which of the database columns shown
above are authorized for the current user.
Modify your application to ask which columns the current user is
authorized for.

1. Create a Policy on TENANT.styra.com

The policy you are about to write takes as input:

the user requesting information
the employee whose information is being requested

For simplicity, we are hard-coding user-data into the policy,
but you can use TENANT.styra.com to import that data from LDAP
or ActiveDirectory.

Go to TENANT.styra.com > Policies > Add and copy-paste the following text into the editor. Then click the Publish icon (an up-arrow) in the upper-right corner of the editor.

package columns

# deny SSN to anyone other than the user and HR
deny["ssn"] {
   input.user != input.employee
   not is_hr(input.user)
}

# deny phone number to general public
deny["phone"] {
   input.user = ""      
}

is_hr(user) {
  employees[user].roles[_] = "hr"
}

# Could be imported from LDAP/AD, instead of hard-coded in policy.
# If imported from LDAP/AD, format would be different, which
#   would require is_hr function to change
employees = {
    "bob": {"manager": "janet", "roles": ["engineering"]},
    "alice": {"manager": "janet", "roles": ["engineering"]},
    "janet": {"roles": ["engineering"]},
    "ken": {"roles": ["hr"]},
}

2. Create a Service Account for TENANT.styra.com

Your application needs a service-account to talk to TENANT.styra.com,
so create one.

Go to TENANT.styra.com > ☰ > API Tokens
Click “Add API Token” at the bottom of the dialog and enter the following settings
- Pathname: enter a name you haven’t used for a service account.
Click OK
Copy the Secret (you won’t be able to retrieve it after this step)
Click Done

3. Integrate Application to ask for Database Column Decisions

Every time a user asks for employee data, your application will
make an API call to TENANT.styra.com to ask for the database
columns the user is authorized to see.

Every time the admin asks to see the current user-role assignments,
your application retrieves them from TENANT.styra.com/v1/data/columns/deny.

Below you use the token you just generated to ask about the database
columns when alice asks for bob's employee information. In this case
alice is prohibited from seeing the ssh column.

curl -X POST 'https://<TENANT>.styra.com/v1/data/columns/deny' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": "user": "alice", "employee": "bob"}'

["ssn"]

An unauthenticated user asks for bob's employee information. She is
prohibited from seeing the ssh and phone columns.

curl -X POST 'https://<TENANT>.styra.com/v1/data/columns/deny' \
     -H "Authorization: Styra-Token <YOUR-TOKEN-HERE>" \
     -d '{"input": "user": "", "employee": "bob"}'

["ssn", "phone"]

Once the application knows which columns to skip, it can remove those
from the database query it runs.

Wrap Up

Congratulations on finishing the tutorial!

You learned how to use TENANT.styra.com to add policy-based control
to which database columns your users see.
In particular, you learned

How to write policy that decides which database columns to
hide from the user.
How to integrate your application with TENANT.styra.com’s
RESTful API

While the tutorial was aimed at databases, the same setup works
for any kind of service where your application controls which
fields are shown to the user.

Followers: 1

Resources:

Product Website Terms of use

API Creator:

Styra, Inc

styraZaas

Rate API:

Rating: 5 - Votes: 1