What are policies?

Policies are re-usable rulesets 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 re-used 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 a ConductorOne tenant.

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 automations.

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, 3rd parties) - access requires manager approval

Rule 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 completed 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.

Step types

The following is a list of some of the Step types available in ConductorOne:

• 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 fires a synchronous webhook which can be used to drive notifications and/or change the policy steps.
• Wait condition: ConductorOne waits until a condition is true.

Managing policies

ConductorOne provides built-in policies to get you started. To view these and any other policies currently saved in your ConductorOne instance:

1. In the navigation panel, open Admin and click Policies.

Create a new policy

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 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. Select a reviewer:

2. If you selected Manager, Group, Account owner, or Entitlement owner in Step 1, 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.

6. 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.

7. Click Save.

Step 4: Add followup on execution

For revocation 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.