Groups Tab
Use the Groups tab to create or delete groups and subgroups, assign users to them, associate them with specific Access Control permissions, define group attributes, and specify group membership behavior. As mentioned in the conceptual discussion earlier in this chapter, Groups are key to modeling your organization and granting or denying access to various resources to several users.
Note: As of Release 2017 R1, there are two changes to group management:
Group membership is now handled separately from any LDAP Maps, EXCEPT for the system defined special groups All Users, System Admins, and VPE Admins. All other user-defined groups must be provisioned manually.
Group membership changes are handled by the Group Membership Process that automatically runs when you use the Publish command to commit your changes, or as the final process of an automated LDAP Synchronization job. The process runs only if a change has occurred on the Users, Groups, or Permissions tabs. It cannot be invoked or cancelled manually.
Here is how the Groups dialog might look at your site before any major Access Control configuration.
Out of the box, you will see four system-defined groups:
All Users
System Admins
Super Users (a sub-group of System Admins)
VPE Admins
The lower-case names in parenthesis are the system equivalent names that you would specify if importing/exporting groups via spreadsheet. ("Import and Export" above).
These system-defined groups have the following default settings:
All Users: no type (nothing is shown in the UI; it is handled automatically by aPriori; the UI does not allow users to be added or removed)
System Admins, VPE Admins: Manual
Super Users: Manual (and this cannot be changed).
When an admin edits the group membership type for an existing group and enters a different type, the following rules should apply.
Old Group type: None, New Group type: Manual or Automated
Action: do not change the current group membership (note that the next Group Membership Process invocation will fix up the membership if it needs to change)
Old Group type: Manual, New Group type: None
Action: Remove current members (who are not populated by a child group)
Old Group type: Manual, New Group type: Automated
Action: Do not change the current group membership (the next Group Membership Process invocation will fix up the membership).
Old Group type: Automated; New Group type: None
Action: Remove current members (unless they are populated by a child group)
Old Group type: Automated; New Group type: Manual
Action: Remove current members (unless they are populated by a child group)
To Add, Edit, or Remove groups or sub-groups
To add a new group, click the New Group button:
To add a new sub-group, select an existing group and click the New Sub-Group button:
To edit a group or sub-group, select it and click the Edit Group button:
Note that you can only edit the name or the Group Membership setting with this button. To edit the Permissions, Members, or Attributes of a group or sub-group, select it and use the panes on the right side of the window. Further note that you cannot edit the All Users or Super Users groups at all, and only the Group Membership setting for System Admins and VPE Admins.
To remove a group or sub-group, select it and click the Remove Group button:
Note that you cannot delete any of the four system-defined groups (All Users, System Admins, Super Users, or VPE Admins).
Group Membership settings
This setting determines how user are associated with groups:
None – The group contains only users from sub-groups. You cannot add or remove users from directly through the UI.
Manual – The group contains users who are assigned through the UI, or by importing user/group associations (see Import and Export).
Automated – The group is populated by the Group Membership Process. These groups have a new memberOf permission associated with them.
Note that for LDAP connections to have the System Admin and VPE Admin options available for the Sync Admin Group Membership settings (see To add a new LDAP connection), these groups must be set to Manual here.
Associated Permissions, Members, and Attributes panes
The Associated Permissions pane displays the permissions that currently apply to the selected group. In the screen shot above, all permissions shown are the system-defined permissions available Out-of-Box , as identified by the "ap." naming prefix.
The Members pane displays the users who belong to the selected group.
The Attributes pane allows you to define, associate, and remove attribute/value pairs for the selected group. To create a new attribute, double-click the Name field for the first unpopulated row and enter a name for the attribute. Double-click the Type field to display a pull-down menu from which you can select string for text, double for numeric values, Boolean for true/false values, or list for semi-colon-separated strings. Double-click the Value field to enter the value of the attribute.
An example of using the list attribute would be to create a list of VPEs to which the group should have access, such as setting attribute "AC_VPEs" to:
aPriori China; aPriori USA; aPriori Mexico
This could then be used by an Access Control administrator to write a rule similar to:
vpe.name in currentGroup.attributeValues.AC_VPEs
Note: When entering or editing attribute values, you should always press the Enter key when done, and before clicking elsewhere in the UI. Otherwise, the value may not be saved.
When done, click the Publish icon to save the new attribute and make it available to other groups.
UDAs and Group Attributes
Note that group attributes are separate from User Defined Attributes (UDAs) which apply only to component scenarios. However, you can manually coordinate group attributes with UDAs. For example, if you implement a region-based Access Control model, you might create both a group attribute and a UDA named "Region" and set them to values such as "NA" for "North America" or "EMEA" for "Europe, Middle East, and Africa". Once defined, you can then create permission rules that ensure that members of a group with the "Region" group attribute set to "NA" can only access component scenarios. You must ensure that you implement the names and values EXACTLY so that rule comparisons return valid results.