Polar's Built-in Types
Unlike many logic programming languages, Polar uses explicitly typed data.
When you first open a Polar policy, there are two classes of types available to you.
| Class | Description |
|---|---|
| Primitive | Represents literal values, such as numbers. |
| Abstract | Represents a type that you want to represent in your authorization policy, such as users and organizations. |
Note that this page only discusses built-in types. Most of the authorization policy you write will be in terms of your own types, modeled as resource blocks.
Primitive types
Polar supports the following primitive types.
| Type | Description | Example |
|---|---|---|
String | String of text | "a" |
Integer | 64-bit signed integer | -3 |
Boolean | true or false values | true |
You can use these values in rule parameters or facts, e.g.
is_string_a(x: String) if x = "a";
Common uses of String
Polar resource blocks
documentation contains more details but, by convention, Polar represents the
names of permissions, roles, and relation using String values.
Object literal representation
In addition to the typical literal representation, you can also express
primitive values as object literals by using their type name (e.g. Boolean)
followed by a literal value of the appropriate type (e.g. true) surrounded by
curly brackets ({}), e.g.
Boolean{true}
This notation has no semantic effect on the policy.
Abstract types
Polar provides the following abstract types to help you express the two primary types of objects involved in an authorization policy.
| Type | Description |
|---|---|
Resource | An object to which you want to authorize types of access. Identify subtypes with the resource keyword. |
Actor | An entity to whom you want to grant types of access. Identify subtypes with the actor keyword. |
To create your own types, you will extend these abstracts using resource blocks.
Polymorphism
Abstract types' purpose is to support polymorphism for your policy's resources.
To better understand polymorphism in Polar, see the documentation for
extends.
Among Polar's built-in types, the following polymorphic relationships exist:
| Supertype | Subtype |
|---|---|
Resource | Actor |
Object literal representation
You should never represent abstract types as object
literals, e.g. never use
Resource{"foo"}.
Up next
- Rules + facts to understand how to begin modeling your application.
- Resource blocks to begin creating your own types.
Talk to an Oso engineer
If you want to learn more about Polar, schedule a 1x1 with an Oso engineer. We're happy to help.