Understanding Policies in the Platform
An Authorization Policy defines the relationship between Who (Identities) and What (Assets). When an Identity, typically represented as a user in a Dynamic Groupm wants to perform an Action on an Asset, the Platform determines which Policies apply and what access is allowed. Policies can grant access to Assets or define permissions for specific actions, such as view, update, delete, or approve. The Application is the mechanism through which the Identity interacts with the Asset to perform the Action.
To make Policies more granular, additional objects like Conditions are used. Conditions define when access is allowed, based on factors such as date and time, IP address, Identity Attributes, and Request Attributes.
Example: A manager accessing their account via an online application during working hours.
Policy Catalog
The Policy Catalog contains all Policies within the Environment, regardless of how they were created, whether via the Policy Wizard, imported as Rego code, or discovered from third-party vendors. When a Policy is created, it consolidates all elements into a logical expression of the Organization’s authorization requirements, including:
- Assets and Asset Types
- Identity Attributes
- Asset Attributes
- Policy Custom Attributes
- Actions
- Rulesets
- Conditions
- Applications
- Scopes
Policies can be assigned to existing Dynamic Groups or to new Dynamic Groups created during Policy creation. You can configure as many Policies as needed to fulfill the Organization’s business requirements.
Example: In an online knowledge base containing marketing, sales, and technical materials, a Policy can define which departments can access marketing and sales content versus technical content.
Each Policy consists of one or more Rules, grouped into a Ruleset. Each Policy must have at least one Ruleset, which must contain at least one Rule.
Policy Icons
| Icon | Meaning |
|---|---|
 |
Policy is Inactive and not considered in authorization decisions. |
 |
Policy Type is Restrictive. |
 |
Policy is incomplete and cannot be used in Authorization decisions. |
Incomplete Policies
If a Policy has not been completed, a red dot will appear next to the Policy listing in the Policy Catalog and the Policy will not be active.
Once you complete the required configurations, the red dot is removed and the Policy will be applied appropriately.
Active/Inactive Policies
Active Policies are included in Authorization decisions. By default, Policies are Active when created or imported. Inactive Policies can be used for testing or onboarding. Importing an Inactive Policy into a new Environment sets it as Active in the target Environment. Updating a Policy does not change its status. See Managing Policies for more information.
Restricted/Allowed Policies
Policies can be configured to either restrict or allow access. A Restricted Policy enforces limitations by denying access when its conditions are met. An Allowed Policy explicitly grants access under the defined conditions. This flexibility lets you decide whether a Policy functions as a safeguard (restricting) or as a permission enabler (allowing), depending on your authorization requirements.