Permissions Tab
Use the Permissions tab to create, view, delete, or modify access rules. These permissions can then be associated with groups via the Groups tab (see previous section). The screen shot below shows how system-defined permissions appear Out-of-Box , before any customization work has been done.
All aPriori-defined permissions have descriptive names starting with "aP." and indicating their purpose. For example, "aP.component.RUD" is a system-defined permission that gives the user Read, Update, and Delete rights to components. aPriori recommends that you define and implement a strict naming convention for any permissions that you develop for your site.
Note that you do not necessarily need to use a single prefix such as "user." for all of for your own rules: Just the fact that they do not begin with "ap." flags them as user-defined, so you can simply begin your names with categories or some other organizational prefix.
The controls at the bottom of the permissions list allow you to add, delete, copy, or edit permissions:
Control | Purpose |
|---|---|
 | Add – Create a new permission from scratch. |
 | Remove – Delete the selected permission. |
 | Copy – Make a copy of the selected permission, typically to use as a starting point for a new permission, or to make a back-up of a permission prior to editing. By default, the new permission is created with the same name as the source permission, but with "Copy" appended. aPriori displays a dialog so that you can customize the name of the copied permission. |
 | Edit – Make changes to an existing permission. |
Note: When you finish entering or editing a rule, you should make sure to click the pencil Edit icon
(
). If you try to go directly to the Publish icon, for example, you may get a message that no rule is defined, or your edits may not get saved.
(
). If you try to go directly to the Publish icon, for example, you may get a message that no rule is defined, or your edits may not get saved.To create a new permission
The general flow for creating a new permission follows the steps show below. Before creating new permissions, you should remember the following important guidelines:
• Develop, modify, and test permissions ONLY in a test environment. Do not deploy a new or modified permission in your production environment until you are 100% confident that it works the way you think it works.
• Keep it simple. Build up permissions incrementally and, again, test them thoroughly before deploying them to your users.
• The UI helps you build the framework of permissions with a "Rule Builder", where the elements of your rule are displayed in the Rule field. You can define simple rules without ever editing the Rule field. However, you can also build quite complex rules using the aPriori CSL (Costing Syntax Language) statements. For advanced implementations such as this, contact aPriori Professional Services, and watch for examples that aPriori will be developing over time.
To create a new permission:
1 You can either start from scratch by clicking the plus-sign Add icon or clone an existing permission to use as a starting point. It is often more efficient to find a rule that is similar to what you want, copy it, and modify the copy.
2 To start from an existing permission, select the rule you wish to copy and click the Copy icon.
3 Whether you are Adding a new permission or starting from a Copy, aPriori prompts you enter a name, or to edit the default name created for the Copy. Click OK when done.
4 Enter a descriptive string in the Description field.
5 From the Resource drop-down menu, select the target of this permission:
6 From the Action section, select either Create or Use. If you select Use, you must select at least one of the actions provided. Only actions that are valid for your selected resource are enabled.
7 Set the rule for this permission. If the permission is to be Always or Never true, aPriori automatically sets the permission and displays it in the Rule field. You cannot edit an Always or Never rule. However, if you want to define a more complex rule that, for example, compares the value of a group attribute with the value of a scenario User Defined Attribute, you can select When this rule is true and build up the expression. The rule is displayed in the Rule field, and you can click the pencil Edit icon to edit and fine-tune the rule. Do not forget to click the pencil Edit icon again when leaving the Rule field.
Note that you build rules in a general left-to-right workflow: and your available options are determined by the settings that you choose for the Resource: pull-down menu and the Action: buttons and checkboxes:
- Choose the “noun” for the rule from the Subject column drop-down menu. For example, “vpe”.
- Choose the attribute for the Subject from the Property drop-down menu. For example, “vpeType”.
- Choose a comparison symbol from the Operator drop-down menu. For example, “!=” for “not equal”.
- Choose another noun for the right side of the equation from the second Subject drop-down menu. For example, “CONSTANT” to specify a string,
- Choose another attribute for the right side of the equation. Note that if the drop-down menus do not provide the value you need, you can always click the pencil icon from the upper-right of the Rule: field and manually edit the rule that you are building. For example, the only canned values available from the Property drop-down menu when the Subject is “CONSTANT” are “false: and “true”. But maybe you want to test that the value of the “vpeType” is not a label that your company has created and assigned to European VPEs, such as “EU_ONLY_VPE”. In this case you can manually edit the Rule field and enter ‘EU_ONLY_VPE’ (in single quotes) on the right side of the “!=” operator, You could then assign this rule to groups of North American users to ensure that they cannot use the EU VPE(s).
Group Membership Considerations
This section describes permissions added in Release 2017 R1.
To create a Group Membership permission
As of Release 2017 R1, a new a new Resource target (“User”) and a related new Action (“Member Of”) were introduced to support automatic group population for any group that has a membership setting of “Automated” (see Group Membership settings).
These permissions will typically compare attributes of the user to the attributes of the group. For example,
User.department == currentGroup.attributeValues.AC_Department
When the group membership permission is checked, it denies or grants to indicate whether the user is a member of the current group. A group can have more than one membership permission.
Here is a simple example that tests whether the value in the user attribute “department” is equal to the group’s attribute “Business_Unit”.
1 In the Groups tab, create a group with a Group Membership setting of Automated, and create an attribute called “Business_Unit” of type String with a value of “Finance”.
2 Go to the Permissions tab and create a permission with a User resource and Member Of action that compares the user’s department to the group’s Business Unit:
3 Publish when done.
4 Return to the Groups tab and add the permission that you just created. Click the Add (+) icon next to Associated Permissions, search for the name of the permission you just created, then select it and click OK.
5 Publish when done.
Your members list should become populated with all users who match the query:
Group Membership Algorithm:
Here is how the Group Membership Process handles these permissions:
1 For each Automated access control group, check if a user is a member of that group by invoking each group membership permission.
2 Apply normal access control semantics if there is more than one of these permissions on the group (for example, a strong deny would trump a normal grant). In addition, since a user would also be a member of the group’s parent groups (all the way up to All Users), all group membership permissions for each group in this branch are checked.
If a user is a member of a subgroup, then they are also a member of the parent group. This access control rule cannot be violated. So, if a parent group is also an Automated group and has a group membership permission that returns a deny, the user would be a member of both the child and parent groups. If the parent group’s permission returned a strong deny then the user would not be a member of either group.
3 Overwrite the group membership for all AC groups that are tagged “Automated”.
“None” groups are also affected (for example if a None group was a parent of an Automated group.
“Manual” groups can also be affected (for example if a parent group is an automated group and its group membership is changed the manual group could be affected)
The interaction between group types and parent/child groups is summarized below:
Parent/Child | Manual | Automated | None |
Manual | Child users are in the Parent Group (If removed from the Parent Group they are removed from the child group too, but not vice versa). | Child users are included in the Parent Group (cannot be removed from the Parent Group). | Indirect child users are members in the Parent Group. |
Automated | Child users have to pass Parent’s membership rules to be allowed into the Child group. For example, a normal deny by the parent would allow manual entry into the Child group. A Strong Deny would not allow entry into the Child group. (Manual membership acts like a grant.) | Child users have to pass both Child and Parent’s membership rules to be allowed into the Child group. For example, a normal deny by the parent and grant by the child would allow entry into the Child group. | Indirect child users are members in the Parent Group. |
None | Child users are in the Parent group. | Child Users have to pass Child membership rules and then they are members in the Parent group. | Indirect child users are members in the Parent Group. |
Note: This table focuses on one level of the hierarchy; but these rules are checked for the full branch of the tree (from the leaf nodes right up to All Users).
For example:
1 Parent = Automated, Child = Manual or Automated
2 User X is added to a Child group which satisfies the Parent membership rule
3 At some future time, the Parent membership rule is changed (the Permission is changed, or one of the attributes that the Permission uses changes) such that User X no longer satisfies the Parent membership rule
Membership of the Child group depends on what the Parent membership rule does:
- If the parent rule is a normal deny, and the child membership rule returns grant then nothing would change (since we treat a manual association as a grant in the case that the child group is manual).
- If the parent rule is a strong deny then the parent membership permission wins/trumps and the user is removed from the child group (and all the way down the chain unless there was a strong grant).