What are policies?

Policies are reusable rule sets that define a workflow for requesting, reviewing, or revoking access. Policies are extremely powerful, as they allow you to bundle similar workflows into a single policy that can be reused across applications, resources, and entitlements.

Here are a few examples of policies that can be created in ConductorOne:

These are just a few examples of policies that can be created in ConductorOne.

By default, all ConductorOne tenants are created with a set of baseline best practice policies that can be used out of the box.

Policy types

There are three policy types in ConductorOne:

• Request: these are policies that can be used for granting access to roles, apps, resources, and entitlements.
• Review: these policies are used to define access review workflows.
• Revoke: these policies are used for revoking access.

Use revocation policies if you want to bring a human in the loop to confirm removing access. This is very effective as a speedbump, particularly where you are using JML automation.

Policy rules

Policies are built on rule sets. Policy rules allow you to build review, request, and revocation workflows in which a single policy’s instructions vary based on the context of the request.

For example, you may have an “IT Essentials” access request policy. This policy could have two rules:

• Rule 1: For employees - access is auto-approved
• Rule 2: For everyone else (contractors, third parties) - access requires manager approval

Rules allow for configuring pre-approvals and/or complex rule logic based on an extensible set of conditions. Ultimately, this allows companies to streamline access management process by reducing risk while removing human-in-the-loop approval where unnecessary.

The baseline rule

Each policy starts with a “baseline” rule and you can support up to 16 additional rules. The baseline rule sets the action to be taken if no other rules are present or if no other rules match. ConductorOne reads policies from top to bottom, taking action as soon as it finds a matching condition. When forming your conditional policy, make sure you organize the rules you create from most to least specific.

Here’s an example. This request policy has three rules plus a baseline:

• Rule 1: If the user is a contractor, auto-deny the request.
• Rule 2: If the user’s job title is Designer, assign the request to the head of Engineering.
• Rule 3: If the user works in the Engineering department, auto-approve the request.
• Baseline rule: If the user does not match any of the rules above, assign the request to the user’s manager.

Based on the construction of this policy, a user with the job title Designer who works in the Engineering department will have their request assigned to the head of Engineering. If Rule 2 and Rule 3 were reversed, however, the same user would have their request auto-approved.

Policy rule steps

Policies enable you to bring humans into the loop on approvals and reviews. They ALSO allow you to fire webhooks, wait until conditions are true, and more. This extensibility is extremely powerful for scenarios such as:

• Waiting until security training is complete before granting access
• Sending a notification on approval
• Changing the approval flow dynamically using an external system’s logic

Each of these is created as a “Step” in a policy rule. Rule steps define basic workflow steps that are executed when the rule is matched. These step types allow for significant flexibility of identifying the right human (if a human in the loop is required for approval) and/or executing external workflows, waiting for conditions, and more.

Create a new policy

ConductorOne provides built-in policies to get you started. You can view these and any other policies currently saved in your ConductorOne instance on the Policies page.

If the existing policies don’t match the workflow you need, create a new policy.

Step 1: Set up the new policy

1. In the navigation panel, open Admin and click Policies.
2. Click New policy.
3. Give your policy a name and an optional description.
4. Select the relevant policy type from the Policy type menu.
5. Click Continue. The policy’s details page opens.

Click the pencil icons in the policy’s header if you want to edit the policy’s name or description.

Step 2: Add policy rules

1. Click Manage rules in the Rules section of the page.
2. Click Insert a rule above to add a conditional rule to your policy.
3. In the If this condition matches: box, choose how to form your policy rule:
   • Use the Basic condition builder to construct a rule from a combination of entitlements and profile attributes, with the option to add and and or statements to refine the rule.
   • Use the Expression field to to compose a CEL expression that describes the membership rule.
4. In the Then perform this action: section of the rule, select an automatic action (the exact actions vary by policy type) or Execute a workflow to wait for a condition to be met or assign the task to a reviewer workflow (see below). If necessary, click Add step to add additional actions or workflows to the rule.
5. Repeat the Add another rule process, adding as many conditional rules as needed. If necessary, you can use the arrow keys to change the order of your rules. Remember, for best results place more specific rules before less specific rules.
6. Edit the baseline rule. The baseline rule can be set to take an automatic action (the exact actions vary by policy type), or to assign the task to reviewers, as described below.
7. Click Save.

Step 3: Define the rule steps

If you choose the Execute a workflow option for your policy rule, here’s what to do:

1. Choose Assign for review or Wait for condition, then skip ahead to the relevant instructions below.

Wait for condition

1. Give the condition a name. This is shown in the policy

2. Enter a CEL expression that describes the condition that must be met before the policy is allowed to move forward.

3. Optional. Enter a comment that will be posted on the task’s details page during the wait period. This helps users and other reviewers understand what needs to happen to move the task forward.

4. Select the timeout period for the wait step.

5. Optional. Enter a comment that will be posted on the task’s details page if the wait period times out before the condition is met.

If needed, click Add reviewer step to add either another wait condition check or a reviewer flow that will begin once the condition has been met or timed out.

Assign for review

1. Select a reviewer:

   • User: ConductorOne will assign the task to the specific individual or individuals who you select as reviewers.
   • Group: ConductorOne will assign the task to the members of the selected group. Only one member needs to complete the task, but all members will be notified. If there are more then 128 members in the selected group, the task will not notify the group’s members, but will instead use the fallback reviewer.
   • Manager: ConductorOne will identify the user’s manager (via the information pulled from your company’s identity provider) and assign them the task.
   • Account owner: The task will be assigned to the user identified as the owner of the application account in ConductorOne. In almost all cases, selecting this option results in a self-review of the access.
   • App owner: The task will be assigned to the owner or owners set for the application in ConductorOne.
   • Entitlement owner: The task will be assigned to the owner or owners set for the entitlement in ConductorOne.
   • Resource owner: The task will be assigned to the owner or owners set for the resource in ConductorOne.
   • Expression: ConductorOne will evaluate the Common Expression Language (CEL) expression you enter here and assign the task to the returned user. See Write conditional policy rules for examples and more instructions.
   • Webhook: ConductorOne will fire a synchronous webhook which can be used to drive notifications or change the policy steps. See Webhooks for instructions on setting up webhooks.

2. If you selected Manager, Group, Account owner, or Entitlement owner, you have the option to provide a fallback reviewer. In the event that ConductorOne cannot identify the specified reviewer on a task (or the task is assigned to a group with more than 128 members), the system will fall back to the secondary reviewer you set here.

   • If you check Permit reviewer to reassign task on the policy, the fallback reviewer can then reassign the task to an appropriate contact.
   • Multiple fallback reviewers can be listed, but only one needs to take action.

3. Set whether the reviewer (or the fallback reviewer, if applicable) can reassign the task, and whether reassigned tasks require a reason for their reassignment.

4. Set whether a reviewer can complete a review that they are the subject of. (This option is not available for Account owner reviews since these reviews are generally self-reviews.)

5. Set whether approvals and denials require the reviewer to enter a justification for their choice.

Finally, if more than one approval step is needed (for instance, if first a account owner self-review and then a manager approval is required), click Add reviewer step and repeat Steps 1-5. Or, to add a wait condition,

If needed, click Add reviewer step to add either another approval step (for instance, if first a account owner self-review and then a manager approval is required) or a wait condition that will pause the policy’s progress until a certain benchmark is met.

Step 4: Add post-execution actions

For review tasks only.

1. In the Post execution actions section of the page, set whether ConductorOne should automatically revoke access if the access review is denied.

That’s it! Your policy is now ready for use. You can review or edit the policy’s details any time by clicking on its name on the Policies page.