Create IT Team Attributes

You have explored the users and attributes that came from your Identity Provider. Those attributes describe your people at the department or large-team level, but they rarely capture the small teams and functions where only a handful of users should have access to a system. This walkthrough builds one example team dimension around Wren Odell’s IT security team — a set of IT Security Engineers — creating the dimension, adding team attributes, and writing the attribute, manager, and named-user rules that decide who belongs to each one.

What you’ll learn

Create a custom Team dimension and add team attributes to it.
Write policy rules that match users by attribute, by manager, and as named users.
Nest one team inside another by using a team attribute as a rule condition.
Stage, review, and activate rules so access is granted only when you are ready.
Reuse a single team definition across every resource that attaches to the attribute.

Prerequisites

A workspace with a completed Okta or Google Workspace integration sync.
The prv CLI authenticated to your workspace.
Familiarity with exploring users and attributes.

The IDs shown below (drdim_…, dratr_…, poset_…, porul_…, and so on) are examples. Your records will have their own IDs. Where a command needs an ID you provide, it is written as an UPPERCASE_TOKEN that you replace with the real value from the previous step’s output.

1. Review dimensions with attributes enabled

List the dimensions that have attributes enabled

The profile data on your users comes from your Identity Provider, and that data is usually sourced upstream from your Human Resources Information System. It describes your users at a department level or at a large team level, and it does not always describe the smaller teams and functions where only five or ten users should have access to a system.In this step you will create a dimension of your own to represent those teams, add attributes to it for each team, and write the policy rules that decide who belongs to each one. A user can belong to more than one team at the same time, so a user with a department of IT can also be a member of several security teams simultaneously.The starting point is a list of directory dimensions filtered to the ones that have attributes enabled. These are the dimensions that were created from your Identity Provider data, and there are 7 of them in your directory.

prv directory-dimension:list --where=attributes_enabled=true

2. Create the Team dimension

Open the Create Dimension option

In the Next Step menu, press the ↓ arrow until the radio option reaches Create Dimension and press ENTER/RETURN.

┌ Next Step ──────────────────────────────────────────┐
│   ○ I'm all set!                                    │
│   ○ Describe/Manage Dimension                       │
│   ○ Create Attribute for Dimension                  │
│   ○ Filter List of Results                          │
│   ○ Edit Column Display Settings                    │
│   ○ Reset List Filters                              │
│   ○ Run Same Command (to get refreshed results)     │
│ › ● Create Dimension                                │
│   ○ Deprecate (schedule expiration for) Dimension   │
│   ○ Deactivate Dimension                            │
│   ○ View Soft Deleted (Expired/Deactivated) Records │
│   ○ Export Results to File or Spreadsheet           │
│   ○ View Raw JSON Output                            │
│   ○ Manage a Different Resource                     │
└─────────────────────────────────────────────────────┘

Name and confirm the dimension

Name the dimension team and confirm that you are good to go. You can be more descriptive if your organization uses a different word for these groupings, since the wording is your choice.Provisionr responds with Dimension Created Successfully and describes the new record.

Describe the new dimension

prv directory-dimension:describe --id=TEAM_DIMENSION_ID

┌ Dimension ───────────────────────────────────────────────┐
  id                       drdim_01abc123...
  state                    active
  integration_id
  integration_type
  profile_key
  name                     Team
  handle                   team
  attributes_enabled       true
  conditions_enabled       true
  expires_after_days       30
└──────────────────────────────────────────────────────────┘

┌ Child Relationships ─────────────────────────────────────┐
  Directory Attributes  0
  Audit Logs Parent     0
  Audit Logs Record     2
  Audit Logs Related    0
└──────────────────────────────────────────────────────────┘

Review the dimension record

The dimension is created with attributes and conditions enabled and with an expiration default of 30 days, and it has no attributes on it yet.

3. Add an attribute to the dimension

Open the Add Attribute option

The dimension holds the teams, and each individual team is an attribute on that dimension. Select the Add Attribute to Dimension option from the Next Step menu.

┌ Next Step ─────────────────────────────────────────────┐
│   ○ I'm all set!                                       │
│   ○ View/Manage Related Attributes                     │
│ › ● Add Attribute to Dimension                         │
│   ○ Deprecate (schedule expiration for) this Dimension │
│   ○ Deactivate this Dimension                          │
│   ○ Create another Dimension                           │
│   ○ Update this Dimension                              │
│   ○ Refresh this Data from the API                     │
│   ○ View Raw JSON Output                               │
│   ○ View Audit Logs for this Dimension                 │
│   ○ List of Dimensions                                 │
│   ○ Manage a different resource                        │
└────────────────────────────────────────────────────────┘

prv directory-attribute:create --directory_dimension_id=TEAM_DIMENSION_ID

Name and activate the attribute

IT Security is made up of several teams, so this attribute is for the identity engineering team inside IT Security. Type IT Identity Engineering Team as the Name. The Handle is derived for you as it-identity-eng-team, so you can accept it.You are then asked whether to override the expiration default that the attribute inherits from the dimension. Leave the No option selected and press ENTER/RETURN, then answer Yes to activate the attribute.

┌──────────────────────────────────────────────────────────────────────────────┐
You can deactivate a Attribute at any time. You can also use deprecation to have
a grace period for changes to be made for users and services before users lose
access. This is helpful for job role changes where users need a few days or
weeks of overlapping access. This is inherited by the dimension unless you
override it for this Attribute.
└──────────────────────────────────────────────────────────────────────────────┘

┌ Override the dimension expires_after_days default (30 days)? ┐
│   ○ Yes                                                      │
│ › ● No                                                       │
└──────────────────────────────────────────────────────────────┘

4. Review the attribute’s policy ruleset

Review the ruleset relationship

The describe output for the new attribute shows a Policy Ruleset alongside the Directory Dimension it belongs to. The attribute has a one-to-one relationship with a ruleset, and that ruleset is what governs who gets access. A user must match at least one of the rules in the ruleset to be added to the attribute.No rules exist yet, so every count on the attribute is zero.

┌ Child Relationships ─────────────────────────────────────┐
  Attribute Conditions     0
  Attribute Predecessors   0
  Policy Rules             0
  Manifest Users           0
  Qualified Users          0
  Staged Users             0
  Audit Logs Parent        0
  Audit Logs Record        2
  Audit Logs Related       0
└──────────────────────────────────────────────────────────┘

┌ Directory Dimension ─────────────────────────────────────┐
  id                drdim_01abc123...
  state             active
  integration_id
  integration_type
  profile_key
  name              Team
  handle            team
└──────────────────────────────────────────────────────────┘

┌ Policy Ruleset ──────────────────────────────────────────┐
  id  poset_01abc123...
└──────────────────────────────────────────────────────────┘

The set of users who match is called the manifest. It works the same way as the manifest for an airplane, a train, or a ship, where the record is a list of who belongs on board rather than a record of how each person got there.

5. List the empty manifest

List the ruleset's manifest users

Select the View/Manage Policy Manifest Users option to list the users on the manifest for this ruleset. No rules have been added that would qualify anyone, so the list is empty.

prv policy-user:list --policy_ruleset_id=POLICY_RULESET_ID

No Policy User records exist

6. Create the first policy rule

Create the rule and add a justification

Use Describe/Manage Parent Relationship to move back up from the manifest list to the attribute, then select Create Policy Rule.Each rule carries a role. Users added through a directory attribute are members of that attribute, so accept the Member role. Other resources may offer an owner, a manager, or the other role-based access control roles that those systems support.You are then asked whether to add a justification description. Answer Yes and type a short sentence. This description is what an auditor or a compliance engineer reads to tell at a glance whether the access is a one-off case or expected behavior.

┌──────────────────────────────────────────────────────────────────┐
A rule does not have a description by default unless it was
imported during Integration sync for a Dimension Attribute.

For custom rules like this, you can (optionally) provide a short
sentence explanation for at-a-glance justification to streamline
user access reviews.

If not set, the rule will be created with a placeholder description.
└──────────────────────────────────────────────────────────────────┘

┌ Description ─────────────────────────────────────────────────────┐
Everyone who reports to this manager is an Identity Engineer.
└──────────────────────────────────────────────────────────────────┘

Continue into the condition

The rule is created in a staged state and the CLI moves straight on to creating a condition for it.

┌──────────────────────────────────────────────────────────────────────┐
Your rule has been created. You can add or remove conditions while the
rule is in a staged (draft) state. No users will be granted access while
the rule is in a staged state.

You can activate your rule when you are finished adding conditions, have
reviewed the list of staged users, and are ready to grant users access
to the Directory Attribute.

Active rules are read-only (cannot change conditions).
You can duplicate the rule to make a new revision in a staged state.
You can deprecate (schedule expiration) or deactivate the existing rule.
└──────────────────────────────────────────────────────────────────────┘

prv policy-condition:create --policy_rule_id=POLICY_RULE_ID --no_describe

┌ Select a Condition Type ───────────┐
│ › ● Users attached to an Attribute │
│   ○ Users reporting to a Manager   │
│   ○ Identity Metadata String Match │
│   ○ Named User                     │
└────────────────────────────────────┘

7. Add a condition on an existing attribute

Choose the attribute condition

Identity Metadata String Match is available, and it is not the option used here. When Provisionr imported your directory data it created an attribute for every value it found, so an attribute for the IT Security Engineer job title already exists and does not need to be rebuilt as a string match.Leave Users attached to an Attribute selected. You are then asked whether to pick the attribute from a user. Select No - Search for Attribute, choose the Title dimension, and choose the IT Security Engineer attribute.

┌ Use a User to select an Attribute? ┐
│   ○ Yes - Use Existing User        │
│ › ● No - Search for Attribute      │
└────────────────────────────────────┘
  You can choose an attribute from an existing user instead of searching all attributes

Save the condition

That attribute already has 20 users associated with it. Answer Yes to save the condition, and Provisionr recalculates which users match the rule as it stands.

Rule Conditions

┌──────┬───────────┬──────────────────────────────────────────────────┐
│ id   │ type      │ description                                      │
├──────┼───────────┼──────────────────────────────────────────────────┤
│ qzhk │ attribute │ Users attached to the IT Security Engineer title │
└──────┴───────────┴──────────────────────────────────────────────────┘
1 Records

Review the staged users

The Staged Users table below the conditions lists every user who currently qualifies. A rule can have one or more conditions, and you are asked whether to add another one.

┌ Do you want to add another condition to this rule? ┐
│ › ● Yes                                            │
│   ○ No                                             │
└────────────────────────────────────────────────────┘
  Each user must qualify for all conditions to be added as a ruleset user.

Matching the attribute keeps the rule tied to database relationships and cross-reference IDs. If the job title is renamed upstream, the ID does not change and only the display name does, so you only have to change it in one place.

8. Check the filter in a second terminal

Filter the directory in a second terminal

Open a second terminal window so you can validate the staged list against your directory without changing anything. Run the user list command, select Filter List of Results, filter by an exact value in a specific field, choose org.title, and select the IT Security Engineer title.

prv directory-user:list

prv directory-user:list --where=org.title='IT Security Engineer'

Review the managers

This returns the same 20 users that the attribute reported. Look at the manager.full_name column in that table, which the staged users display does not include. Those users report to several different managers, so they belong to several different teams rather than one. The identity team is only the users who report to Wren Odell, so the rule needs a second condition.

9. Add a condition for users reporting to a manager

Add the manager condition

Answer Yes to add another condition and select Users reporting to a Manager. Conditions compound on each other, so a user has to qualify for every condition on the rule.The menu lists the managers in your directory, and the condition is stored against the manager’s ID rather than the manager’s name string. Select Wren Odell and save the changes.

┌ Select a Condition Type ───────────┐
│   ○ Users attached to an Attribute │
│ › ● Users reporting to a Manager   │
│   ○ Identity Metadata String Match │
│   ○ Named User                     │
└────────────────────────────────────┘

┌────────────────┬──────────────────────────────────┐
│ Attribute      │ Value                            │
├────────────────┼──────────────────────────────────┤
│ policy_rule_id │ porul_01kytqzj8fktrhk0ng75w5q59k │
│ type           │ manager                          │
│ manager_id     │ drusr_01kytjeg1c9xtc1n1vp9dg9t   │
└────────────────┴──────────────────────────────────┘

Review the recalculated manifest

Saving the condition recalculates the draft manifest. The staged list now holds only the users who carry the IT Security Engineer title and report to Wren Odell, which is a smaller list than the title alone produced. There are 9 users reporting to Wren Odell in your directory.

Rule Conditions

┌──────┬───────────┬──────────────────────────────────────────────────┐
│ id   │ type      │ description                                      │
├──────┼───────────┼──────────────────────────────────────────────────┤
│ qzhk │ attribute │ Users attached to the IT Security Engineer title │
│ w763 │ manager   │ Users that report to Wren Odell                  │
└──────┴───────────┴──────────────────────────────────────────────────┘
2 Records

Decline another condition

Wren Odell does not appear on this list. The rule qualifies users who report to Wren Odell, not the user who is Wren Odell. A team usually has two rules to start with, one for the users who report to that individual and one for the manager as a named user. An assistant, a dotted-line manager, or someone who covers for the team can be added as a named user in the same way.Answer No to adding another condition so that you can activate this rule and create the second rule separately.

10. Activate the rule

Run the activate command

Conditions can be modified while the rule is in a staged state. Staged and draft mean the same thing, and the CLI calls it staged. Once the rule is activated, the conditions are locked and cannot be changed. You can deactivate the rule, deprecate it, or duplicate it into a new staged revision.This is why the justification is captured before activation, so that a rule cannot be approved through change management and then quietly altered afterwards.

prv policy-rule:activate --id=POLICY_RULE_ID

┌ Impact of Decision ──────────────────────────────────────┐
You are deploying to production. You should
know that:

1. After a rule has been activated, you can no longer change
the conditions.

2. To make changes, you can duplicate the rule to replace
this rule with a new version.

3. Any qualified user that matches all conditions will get
access immediately to any groups or resources that use this
policy.
└──────────────────────────────────────────────────────────┘

┌ Do you want to activate the Policy Rule? ┐
│ › ● Yes                                  │
│   ○ No                                   │
└──────────────────────────────────────────┘

Confirm activation

If you are not ready, you can answer No and run the activate command later. Answering Yes returns Policy Rule Activated Successfully.

Active rules are read-only and their conditions cannot be changed. To make a change, duplicate the rule to create a new revision in a staged state.

11. Review the activated rule

Review the rule and its conditions

The rule describe output shows the two conditions and the users they produced. The staged count is now zero and the same users appear as qualified users and as manifest users.

┌ Child Relationships ─────────────────────────────────────┐
  Policy Conditions   2
  Manifest Users      9
  Qualified Users     9
  Staged Users        0
  Audit Logs Parent   2
  Audit Logs Record   2
  Audit Logs Related  9
└──────────────────────────────────────────────────────────┘

┌ Policy Ruleset ──────────────────────────────────────────┐
  id                 poset_01abc123...
  state              managed
  type               directory_attribute
  is_authoritative   false
  expires_after_days 30
└──────────────────────────────────────────────────────────┘

Condition Records

┌──────┬───────────┬─────────────┬──────────────────┬───────────────┬─────────────┐
│ id   │ type      │ profile_key │ profile_operator │ profile_value │ is_imported │
├──────┼───────────┼─────────────┼──────────────────┼───────────────┼─────────────┤
│ qzhk │ attribute │ title       │                  │ it-sec-eng    │ false       │
│ w763 │ manager   │ full_name   │                  │ Wren Odell    │ false       │
└──────┴───────────┴─────────────┴──────────────────┴───────────────┴─────────────┘
2 Records

Qualified users are the users who match a rule. Manifest users are the users who are on the ruleset. When you have several rules and a user matches more than one of them, only one entry supersedes the others, so the manifest count can be lower than the qualified count in the same way that duplicate records are removed.

12. Add a named user rule

Create the second rule

Create a second policy rule on the same ruleset so that Wren Odell is added to the team. Answer Yes to the justification prompt and describe why the manager belongs on the team, then select the Named User condition type.

prv policy-rule:create --policy_ruleset_id=POLICY_RULESET_ID

┌ Select a Condition Type ───────────┐
│   ○ Users attached to an Attribute │
│   ○ Users reporting to a Manager   │
│   ○ Identity Metadata String Match │
│ › ● Named User                     │
└────────────────────────────────────┘

Select the named user

You could name each of the other users individually as well. Rules that are written user by user become difficult to maintain, and keeping the rule tied to data about the user rather than to the user themselves is the reason for the attribute and manager conditions above. Named users cover the circumstances that the data does not, which is usually less than ten percent of the cases.Select Wren Odell from the list of users and save the changes. No population is calculated for this condition, because the user has already been chosen.

Review Your Changes

┌───────────────────┬──────────────────────────────────┐
│ Attribute         │ Value                            │
├───────────────────┼──────────────────────────────────┤
│ policy_rule_id    │ porul_01kytqzj8fktrhk0ng75w5q59k │
│ type              │ user                             │
│ directory_user_id │ drusr_01kytjeg1c9xtc1n1vp9dg9t   │
└───────────────────┴──────────────────────────────────┘

┌ Do you want to activate this rule? ┐
│ › ● Yes                            │
│   ○ No                             │
└────────────────────────────────────┘
  Wren Odell will be granted access immediately. You can activate later if preferred.

13. Review the rules and the manifest

List the rules on the ruleset

Move back up to the attribute and you will see that it now has one more manifest user than the first rule produced on its own. Two different rules justify that access.

prv policy-rule:list --policy_ruleset_id=POLICY_RULESET_ID

The rule list shows both rules, each with its own description, its condition count, and its manifest user count.

List the manifest users

The list of users on the ruleset shows every user in one table.

prv policy-user:list --policy_ruleset_id=POLICY_RULESET_ID

Review the rule IDs

Take note of the rule.id column in that table. The row for Wren Odell carries a different rule ID than the rest, because Wren Odell qualified through the named user rule and everyone else qualified through the reporting rule.

14. Find the Team dimension in the full list

List all dimensions

Run the dimension list without a filter and the new Team dimension appears alongside the dimensions that came from your Identity Provider.

prv directory-dimension:list

Review the Team row

The Team row has no profile_key. The profile key is the name that your provider uses for a field that Provisionr pulls data from, and this data did not come from your provider because you created it. It is a local dimension, so the profile key does not apply.

List the dimension's attributes

Select View/Manage Related Attributes to list the attributes on the dimension, where the team you created is shown with its manifest user count.

prv directory-attribute:list --directory_dimension_id=TEAM_DIMENSION_ID

15. Create a second team attribute

Run the create command

A user can exist on more than one team, so the next attribute covers a second function inside IT Security. This one is for access request management, and both the identity team and the help desk team will belong to it.The command in the recording was mistyped as prv dimension-attribute:create, with the two resource words transposed, so the CLI returned an error. This is a deliberate example of a common mistake — the correct command is prv directory-attribute:create.

❯ prv dimension-attribute:create

  No arguments expected, got "dimension-attribute:create".

Run the create command without arguments and you are asked to select the dimension first. The picker lists only the dimensions that have attributes enabled.

prv directory-attribute:create

┌ Select a Dimension ───────────────────────────────────────────────────────────┐
│ Keyword from id, integration.vendor, name, handle, count.directory_attributes │
├───────────────────────────────────────────────────────────────────────────────┤
│ › drdim_01kytqsrgh52atcfzy7gwyqp92 - n/a - Team - team - 1                    │
└───────────────────────────────────────────────────────────────────────────────┘
  Enter a keyword and/or use ↑ and ↓ arrow keys. Press RETURN to select a list option.

Name and activate the attribute

Choose the Team dimension, name the attribute IT Security Access Request Handlers, accept the derived handle of it-sec-access-request-handlers, decline the expiration override, and activate it.

16. Describe the new attribute

Review the attribute layout

The describe output has the same layout as the first attribute. It sits on the Team dimension, it has a Policy Ruleset of its own, and every user count is zero until you add a rule.

┌ Child Relationships ─────────────────────────────────────┐
  Attribute Conditions    0
  Attribute Predecessors  0
  Policy Rules            0
  Manifest Users          0
  Qualified Users         0
  Staged Users            0
  Audit Logs Parent       0
  Audit Logs Record       2
  Audit Logs Related      0
└──────────────────────────────────────────────────────────┘

17. Use a team attribute as a condition

Add the team attribute condition

The first rule used the job title attribute as a condition. A team attribute can be used the same way, so this rule nests one team inside another. Select Create Policy Rule, add a justification such as the identity engineering team helping with access requests, and choose Users attached to an Attribute.Select No - Search for Attribute, choose the Team dimension, and choose the IT Identity Engineering Team attribute.

┌ Select a Directory Attribute ─────────────────────────────────────────────────────────────┐
│ Keyword from id, integration.vendor, dimension.handle, name, handle, count.manifest_users │
├───────────────────────────────────────────────────────────────────────────────────────────┤
│ › dratr_… - n/a - team - It Identity Engineering Team - it-identity-eng-team              │
└───────────────────────────────────────────────────────────────────────────────────────────┘
  These options have not been filtered based on the conditional users.

Review the staged list

Every user on that team is added to the staged list for this rule, including the manager who qualified through the named user rule. The users were inherited from the upstream attribute, and when that attribute changes the change carries through to everything downstream that uses it.

Rule Conditions

┌──────┬───────────┬─────────────────────────────────────────────────────────┐
│ id   │ type      │ description                                             │
├──────┼───────────┼─────────────────────────────────────────────────────────┤
│ cmn0 │ attribute │ Users attached to the It Identity Engineering Team team │
└──────┴───────────┴─────────────────────────────────────────────────────────┘
1 Records

Activate the rule

Answer No to adding another condition and activate the rule.

The same approach applies to any other resource that you attach to an attribute, such as an application in your Identity Provider, a Google Group, a Slack group, or a GitLab group. You define the team once and reuse it.

Open the menu after the error

Selecting Manage a different resource from the Next Step menu returned an error in the recording. The command that option calls has been renamed, so run prv menu in your terminal to reach the same place.

  ERROR  Command "wizard" is not defined.

prv menu

Navigate the menu

The menu walks you down a namespace, a resource, and an action. Choose Provisionr Directory, then Directory Attribute, then Create a Custom Directory Attribute.

19. Create the helpdesk team attribute

Create and activate the attribute

Create the third attribute on the Team dimension, name it IT Security Helpdesk Team, accept the handle of it-sec-helpdesk-team, decline the expiration override, and activate it.

Check the titles in the second terminal

The users for this team are not known yet, so use the second terminal to look at the titles first. Reset the filters from earlier, filter by an exact value in the org.title field, and type part of the title into the search row.

┌ Filter by Directory User ┐
│ it sec                   │
├──────────────────────────┤
│   IT Security Engineer   │
└──────────────────────────┘
  Enter a keyword and/or use ↑ and ↓ arrow keys. Press RETURN to select a list option.

prv directory-user:list --where=org.title='IT Security Engineer'

Review the titles

Some organizations use generic job titles and some use specific ones, so it is worth checking whether a separate help desk title exists. In this directory there is no help desk title, and every one of these users carries the IT Security Engineer title.

20. Select an attribute from an existing user

Create the rule from an existing user

Create a policy rule on the helpdesk attribute with a justification such as helpdesk engineers having access to their own team, then select Users attached to an Attribute again.This time answer Yes - Use Existing User. Choose a user who already holds the IT Security Engineer title, and the attribute picker lists only the attributes that are on that user.

┌ Use a User to select an Attribute? ┐
│ › ● Yes - Use Existing User        │
│   ○ No - Search for Attribute      │
└────────────────────────────────────┘
  You can choose an attribute from an existing user instead of searching all attributes

┌ Select a Directory Attribute ─────────────────────────────────────────────────────────────┐
│ Keyword from id, integration.vendor, dimension.handle, name, handle, count.manifest_users │
├───────────────────────────────────────────────────────────────────────────────────────────┤
│ › dratr_01kytjhqrqqx8zmczjtpmampy9 - n/a - title - IT Security Engineer - it-sec-eng      │
└───────────────────────────────────────────────────────────────────────────────────────────┘
  These options are filtered based on the selected user.

Add the manager condition

Choose the job title attribute and save the changes. This returns the same 20 users as before, so add a second condition for Users reporting to a Manager and select a different manager from that list. Save the changes, answer No to adding another condition, and activate the rule.

21. Add a named user rule for the helpdesk team

Create another rule for the manager

Select Create another Policy Rule to add the manager. The role picker shows the member role for the directory attribute, and from there the flow is the one you used for the first team.

┌ Select a Role for this Rule ────────────────────┐
│ › porol_… - directory_attribute - member - true │
└─────────────────────────────────────────────────┘

Add the named user condition

Add a justification, select Named User, choose the manager, and save the changes.

Review the manifest

Move back up to the attribute and the manifest count covers both rules. The users who report to that manager and hold the IT Security Engineer title are on the manifest through the first rule, and the manager is on it through the second.

┌ Child Relationships ─────────┐
  Attribute Conditions    0
  Attribute Predecessors  0
  Policy Rules            2
  Manifest Users          6
  Qualified Users         6
  Staged Users            0
└──────────────────────────────┘

22. Find an attribute in the attribute list

Search for the attribute

The access request handlers team was created before the helpdesk team existed, so the helpdesk team can now be added to it. List the attributes across every dimension, select Describe/Manage Attribute, and search for the attribute by keyword.

prv directory-attribute:list

┌ Search for Attribute ──────────────────────────────────────────────────────────────────────────────┐
│ access                                                                                             │
├────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ › dratr_… - n/a - team - It Security Access Request Handlers - it-sec-access-request-handlers - 10 │
└────────────────────────────────────────────────────────────────────────────────────────────────────┘
  Enter a keyword and/or use ↑ and ↓ arrow keys. Press RETURN to select a list option.

23. Add a rule to an existing attribute

Create the rule on the access request attribute

From the attribute, select Create Policy Rule, add a justification such as the help desk handling access requests, and choose Users attached to an Attribute followed by No - Search for Attribute.Select the Team dimension first, which now reports three attributes, and then select the IT Security Helpdesk Team attribute with its six manifest users. Read the results in the picker before you press ENTER/RETURN, since the dimension is selected before the attribute.

Review Your Changes

┌────────────────────────┬──────────────────────────────────┐
│ Attribute              │ Value                            │
├────────────────────────┼──────────────────────────────────┤
│ policy_rule_id         │ porul_01kytqzj8fktrhk0ng75w5q59k │
│ type                   │ attribute                        │
│ directory_attribute_id │ dratr_…                          │
└────────────────────────┴──────────────────────────────────┘

Save the changes

Save the changes. The helpdesk users are now mapped to both teams, and the helpdesk attribute is the source of truth for who they are.

24. Review the rule activation prompt

Review the activation prompt

Answer No to adding another condition and the CLI presents the activation prompt for the new rule.

┌ Activating the Rule ─────────────────────────────────────┐
Activation will immediately add corresponding
policy user(s) manifest and grant access.

If you do not want to grant access, keep the rule
staged and activate later using policy-rule:activate.
└──────────────────────────────────────────────────────────┘

┌ Do you want to activate the rule? ┐
│ › ● Yes - Activate                │
│   ○ No - Staged for later         │
└───────────────────────────────────┘

Activate later if needed

In the recording this prompt was cancelled and the rule was left staged. You can activate a staged rule at any time by running the activate command with the rule ID.

prv policy-rule:activate --id=POLICY_RULE_ID

Orientation

Operations

Coming Soon

Create IT Team Attributes

What you’ll learn

Prerequisites

1. Review dimensions with attributes enabled

2. Create the Team dimension

3. Add an attribute to the dimension

4. Review the attribute’s policy ruleset

5. List the empty manifest

6. Create the first policy rule

7. Add a condition on an existing attribute

8. Check the filter in a second terminal

9. Add a condition for users reporting to a manager

10. Activate the rule

11. Review the activated rule

12. Add a named user rule

13. Review the rules and the manifest

14. Find the Team dimension in the full list

15. Create a second team attribute

16. Describe the new attribute

17. Use a team attribute as a condition

18. Reach the command menu

19. Create the helpdesk team attribute

20. Select an attribute from an existing user

21. Add a named user rule for the helpdesk team

22. Find an attribute in the attribute list

23. Add a rule to an existing attribute

24. Review the rule activation prompt

​What you’ll learn

​Prerequisites

​1. Review dimensions with attributes enabled

​2. Create the Team dimension

​3. Add an attribute to the dimension

​4. Review the attribute’s policy ruleset

​5. List the empty manifest

​6. Create the first policy rule

​7. Add a condition on an existing attribute

​8. Check the filter in a second terminal

​9. Add a condition for users reporting to a manager

​10. Activate the rule

​11. Review the activated rule

​12. Add a named user rule

​13. Review the rules and the manifest

​14. Find the Team dimension in the full list

​15. Create a second team attribute

​16. Describe the new attribute

​17. Use a team attribute as a condition

​18. Reach the command menu

​19. Create the helpdesk team attribute

​20. Select an attribute from an existing user

​21. Add a named user rule for the helpdesk team

​22. Find an attribute in the attribute list

​23. Add a rule to an existing attribute

​24. Review the rule activation prompt

What you’ll learn

Prerequisites

1. Review dimensions with attributes enabled

2. Create the Team dimension

3. Add an attribute to the dimension

4. Review the attribute’s policy ruleset

5. List the empty manifest

6. Create the first policy rule

7. Add a condition on an existing attribute

8. Check the filter in a second terminal

9. Add a condition for users reporting to a manager

10. Activate the rule

11. Review the activated rule

12. Add a named user rule

13. Review the rules and the manifest

14. Find the Team dimension in the full list

15. Create a second team attribute

16. Describe the new attribute

17. Use a team attribute as a condition

18. Reach the command menu

19. Create the helpdesk team attribute

20. Select an attribute from an existing user

21. Add a named user rule for the helpdesk team

22. Find an attribute in the attribute list

23. Add a rule to an existing attribute

24. Review the rule activation prompt