Skip to main content

Authorization Policy

At the core of Aserto’s authorization model is an authorization policy, which we refer to simply as a Policy. Policies are authored in a textual language called Rego, defined as part of the Open Policy Agent (OPA) project in the Cloud Native Computing Foundation.

Policy Lifecycle​

Policies are treated just like application code or infrastructure-as-code. They are authored using a text / code editor, stored in a git repository, built into an OCI binary image, published to a repository hosted on an OCI container registry, run in a Topaz instance, and consumed by an application.

Policy as code

Aserto's Control Plane helps manage the policy lifecycle. For more information on authoring policies and the policy lifecycle, see this topic.

Policy Language Overview​

A policy can include one or more rego files, and one or more JSON data files.

A rego file has a package directive which sets the namespace for the rego file, and defines one or more decisions.

package sample.GET.api.orders

allowed {
  true
}
note

In the rego file above, the package name follows the Aserto convention:

policy-root.HTTP method.HTTP route

Decision​

A decision is an output from the evaluation of a policy. The policy above exports a decision called allowed, and sets its value to true.

The policy below exports the same decision (allowed), has a default value of false for this decision, and a rule that sets allowed to true only if the logged-in users's department attribute is equal to "Sales":

package sample.GET.api.orders

default allowed = false

allowed {
  input.user.properties.department == "Sales"
}

User context​

In the policy above, we were able to use the department attribute to help compute the allowed decision. This is an example of User context that is used in a policy. If you hook up your identity providers and/or directories to the Aserto Control Plane, it will automatically synchronize properties from these sources and make them available to your policies.

User context is automatically resolved and injected into input.user when you pass in an identity context to an authorizer API call.

Users, objects, and the relationships between them are all stored in the Aserto Directory.

Resource context​

Policies can also use resource context in their evaluation process. If we added the allowed clause below to our policy, and the caller included a resource context that contains { "key": "<the-current-user-key>" }, the policy would evaluate allowed to true if the user key and the resource key match.

allowed {
  input.user.key == input.resource.key
}

Built-ins​

To use data from the Aserto Directory in your policies, you can use one of the Aserto built-ins.