Building Policy Rules

Learn how to build policy rules from simple single-condition rules to multi-rule rulesets.

Overview

For Provisionr to automate provisioning and deprovisioning of users for a group or resource (ex. Google Group or Okta Group), we need a pre-calculated list of users that have been pre-approved based on a policy. You build this policy by adding Rules and Conditions to a Policy Ruleset.

For a refresher on these concepts, see the Policies & Rules architecture docs.

Simple Rule for Attribute

For many use cases, a Ruleset will only have one Rule with one Condition. Any user that matches that Condition will be added as a Policy User.

Remember: This ruleset, rule, and condition is automatically created for every Attribute that is detected in your Integration. You do not need to create this manually unless you are adding additional dimensions and attributes that are not managed by your Integration.

Real World Example:

• We have a Division Dimension.
• We have a Sales Attribute that is one of the choices for a division at your organization.
  • You can cosmetically rename the name and slug in Provisionr since the Integration original value is retained in source_value. This is useful if your HRIS or IdP use a different name that is not conducive to the groups and resources that you are managing. For example, this may be the Go To Market division but you want your groups to use the sales slug instead of gtm.
• The Ruleset is automatically created for each Attribute.
• The Attribute’s Ruleset has a single Rule with a single Condition.
  • type: identity - We look at the metadata array for all User Identities imported from the Integration vendor API.
  • source_id: {ulid} - We filter the set of User Identities to a specific Integration (ex. okta).
  • metadata_key: division - We look at the division key in the metadata array for each Identity record.
  • metadata_value: Sales - We filter down to Identities that have division => Sales in their metadata array.
  • metadata_operator: equals - We are looking for an exact match. See Condition Operators for all of the options.

Multiple Condition Rule

You can create a more granular set of users by specifying multiple conditions that need to be true for a User to qualify.

Real World Example:

• We have created a Sales Region Dimension in Provisionr (not imported from an Integration).
• We have created a US Country Sales Team Attribute in Provisionr (not imported).
• The Attribute’s Ruleset has a single Rule with two Conditions.
  • (identity) metadata_key: division and metadata_value: Sales
  • (identity) metadata_key: countryCode and metadata_value: US

There is no technical limit to the number of conditions that you can add to a rule. The best practice practical limit is up to 10 conditions depending on your use case.

Real World Example:

• We have created a Sales Team Dimension in Provisionr (not imported from an Integration).
• We have created a California Sales Account Executives Attribute in Provisionr (not imported).
• The Attribute’s Ruleset has a single Rule with multiple Conditions.
  • (identity) metadata_key: division and metadata_value: Sales
  • (identity) metadata_key: countryCode and metadata_value: US
  • (identity) metadata_key: state and metadata_value: CA
  • (identity) metadata_key: title and metadata_value: Account Executive

The examples above are based on location/territory profile metadata. If your organization has a manager that oversees the sales territory, you can easily include all Users that report to that manager.

Real World Example:

• We have created a Sales Team Dimension in Provisionr (not imported from an Integration).
• We have created a NorCal Account Team Attribute in Provisionr (not imported).
• The Attribute’s Ruleset has a single Rule with an identity type Condition and a manager type Condition.
  • (manager) manager_id: {directory_user.ulid}
  • (identity) metadata_key: title and metadata_value: Account Executive
    • This allows you to only include users with a specific job title. It is up to you whether to include this condition, or simply have all users that report to the manager.

Multiple Rules

Each Ruleset can be expanded to include multiple rules with any combination of conditions to meet your complex use cases.

Here’s the basics to keep in mind:

1. A Ruleset can have one Rule or a set of multiple Rules. Rules are evaluated separately. Any Rule can be true for a user to match ({this} or {that}).
2. There is no such thing as a deny or except rule precedence if a user qualifies for two different rules.
3. Each Rule has one or more Conditions.
4. All Conditions for a Rule must evaluate as true ({this} and {that}) for a user to match.

Resource Rulesets

In the examples above, you saw how an Attribute ruleset works.

A group or resource is functionally identical. Each Google Group, Okta Group, Slack Group, etc has a Ruleset that you can create Rules and Conditions for.

All of these mappings are automated during recurring scheduled sync jobs that fetch user metadata from your Workspace Integrations and the Policy Users and resource users relationships are automatically updated. This means that as user metadata changes upstream, all of the role-based access control logic defined in rulesets automatically grants users access to the respective resources for downstream access grants.