Defining criteria for segmenting users
Criteria allow you to test users in order to define which users belong to a user class. They are extremely flexible filters which act in series. Users only pass the test if they satisfy all defined criteria. This provides many options that can be used in any combination.
There are three types of user class criteria that you can use to determine segmentation:
Attribute criteria – defined by profile and request attributes, and only apply to personal user classes.
Membership criteria – defined by group membership, and only apply to personal user classes.
PSLang criteria – defined by PSLang expressions, and apply to both types of user classes.
You can define as many criteria as you require to properly define your segment of users for the user class.
To define criteria for segmenting users:
Navigate to the User class definition page (Manage the system > Policies > User classes) for an existing user class.
Click the Criteria tab.
Click Add new… in the appropriate section for the type of criteria that you want to add.
Bravura Security Fabric displays a new page for the selected criteria type.
Enter the required information on the criteria page.
If required, repeat the above procedure to add additional criteria to the user class.
Continue to test the user class membership after you add each criteria. This allows for much easier troubleshooting if a mistake occurs while adding user class criteria.
Creating either/or rules for user class memberships
Either/or rules for user class criteria are necessary when users do not have overlapping criteria, but you want them to be part of the same user class. For example, an either/or rule would be required if there was a need for users with membership from two different Active Directory groups to be part of the same user class, but the users did not have membership of both groups. Adding both groups to the user class criteria would result in only users that are members of both groups becoming user class members. Therefore, we need a different configuration.
To achieve either/or rules for user classes, it is best practice to create multiple user classes. User classes themselves do not have the ability to contain either/or criteria rules unless using a PSLang expression. However, the areas of the product that require membership from user classes to assign access and privileges do have the ability to assign multiple user classes. Once multiple user classes are assigned, options appear to determine if users need to be members of both user classes or just one of them to gain the assigned privileges. This is determined by selecting the options for "Any" or "All" for the member user classes listed.
Although it is an option to create a PSLang rule to create either/or criteria definitions, PSLang rules can cause lengthy user class membership calculations, especially for companies with product environments that have many systems and users.
To assign security privileges to users that are part of two different AD groups:
Create user class A for users that have group memberships matching AD group 1.
Create user class B for users that have group memberships matching AD group 2.
Create a security user group containing the desired privilege to be assigned.
In the membership criteria tab of the user group, add both user class A and user class B as members.
An option for users to be part of "All" or "Any" of the multiple user classes appears.
For the option, The participants have to match which of the user classes: select Any of the user classes .
Membership criteria for the security user group is now defined as a user needs to be a member of either user class A or user class B. Users from AD group 1 OR AD group 2 will now have the allowed privileges of the security user group.
For a more detailed example, see Example: Either/or rules for user class memberships .
Adding attribute criteria
On the criteria page:
Select a Participant if you are adding criteria to a relational user class. The participant is automatically selected for personal user classes.
Search for or type the profile/request Attribute to use for the comparison.
If required, enable the Participant’s value must equal the value of this other participant option to compare attributes with another participant. This option is only displayed for relational user classes.
If this option is:
Disabled (default) then you must select a Comparison method.
Enabled, then the Comparison method menu and Value field are replaced by a drop-down list of participants. Select a participant to compare attributes with.
When enabled, you can only compare the same attribute, and the values must be equal to satisfy the criteria. You can compare against a fixed value, or the same attribute of a different user. You cannot define asymmetrical relationships through attribute criteria; for example, the MANAGER INDIRECT user class.
If required, select the Comparison method.
The available comparison methods depend on the type of attribute selected. For example, “starts with” does not appear for date or boolean attribute types.
Disable the Case sensitive comparison checkbox if you want the comparison to be case-insensitive.
By default, this option is enabled, making comparisons case-sensitive.
This option is only available for relational user classes with “character” or “memo” attribute types.
Click Add.
Adding group membership criteria
On the criteria page:
Select a Participant if you are adding criteria to a relational user class. The participant is automatically selected for personal user classes.
Choose the appropriate value from the Membership drop-down list. Select:
Required– to include users who belong to the specified group in the user class.Disallowed– to include users who do not belong to the specified group in the user class.
Search for, or type the ID of the Target system to which the group belongs.
Search for the ID of the managed Group.
Click Add.
Adding PSLang criteria
On the criteria page, type your PSLang expression, then click Add.
Users are included in the class if the expression evaluates to true. Depending on the type of user class, you can include the Participant IDs in your expression. For example:
$USER– In a personal user class, where the participant ID is set to USER.$REQUESTER– In a relational user class, where the participant ID of the requester is set to REQUESTER.$RECIPIENT– In a relational user class, where the participant ID of the recipient is set to RECIPIENT.
To learn the difference between personal and relational user classes, see the User classes introduction.
You can also use the following helper functions, intended specifically for PSLang expressions that define user classes:
getUsersByAttrValue
getUsersByAttrValue( $attrid, $value)
Gets a list of users by attribute value.
Parameters:
attrid | The profile attribute ID to search on. |
value | The exact value to match on. |
Return value: An array of users that match the profile attribute value.
getUsersByGroup
getUsersByGroup( $targetid, $groupid )
Gets a list of users that have group membership to the specified managed group.
Parameters:
targetid | The target system ID. |
value | The long ID of the managed group on the target system. |
Return value: An array of users that belong to a managed group.
getUsersByManager
getUsersByManager( $manager, $direct )
Gets a list of subordinates by manager.
Parameters:
manager | The manager profile ID. |
direct | If 0, the function will return all the managers subordinates in the management chain. If non-zero, the function will return only the managers direct subordinates. |
Return value: An array of subordinates for the manager.
getUsersByRole
getUsersByRole( $roleid )
Gets a list of users by role.
Parameters:
roleid | The role ID to search on. |
Return value: An array of users that have a specified role.
getUserAttrValueFirst
getUserAttrValueFirst ( <userID>, <attributeID> )
Gets the first value of a given attribute for a given user.
Parameters:
userID | The profile ID of the user being evaluated. |
attributeID | The ID of the profile/request attribute. |
Return value: The value of the user’s profile/request attribute.
getUserAttributeValues
getUserAttributeValues ( <userID> , <attributeID> )
Gets multiple values of a given attribute for a given user.
Parameters:
userID | The profile ID of the user being evaluated. |
attributeID | The ID of the profile/request attribute. |
Return value: An array containing the values of the user’s profile/request attribute.
isGroupMember
isGroupMember ( <userID>, <hostID>, <groupID> )
Checks if a user is a direct or indirect member of a given group.
Parameters:
userID | The profile ID of the user being evaluated. |
hostID | The target on which the group exists. |
groupID | The long ID of the group. |
Return value: 1 if true, 0 if false.
isRoleMember
isRoleMember (<userID>, <roleID> )
Checks if a user has the specified role.
Parameters:
userID | The profile ID of the user being evaluated. |
roleID | The ID of the role. |
Return value: 1 if true, 0 if false.
hasAccount
hasAccount ( <userID>, <hostID> )
Checks if a user has an account on the specified target system.
Parameters:
userID | The profile ID of the user being evaluated. |
hostID | The ID of the target system to check. |
Return value: 1 if true, 0 if false.
isManager
isManager ( <userID> )
Checks if a user is a manager in the OrgChart.
Parameters:
userID | The profile ID of the user being evaluated. |
Return value: 1 if true, 0 if false.
accountAttributeGet
accountAttributeGet( <accountID>, <hostID>, <attributeID> )
Gets the value of a specified account attribute for the specified account.
Parameters:
accountID | The long ID of the account. |
hostID | The target system on which the account exists. |
attributeID | The ID of the account attribute. |
Return value: The value of the account attribute.
isLocked
isLocked ( <userID> )
Checks whether a user’s profile is locked.
Parameters
userID | The profile ID of the user being evaluated. |
Return value 1 if true, 0 if false.
reportsTo
reportsTo ( <subordinate>, <manager>, <is_direct>)
Checks whether a user reports to the specified manager.
Parameters
subordinate | The profile ID of the subordinate to check. |
manager | The profile ID of the manager. |
is_direct | If 0 , the function checks the entire management chain. If non-zero, the function checks the subordinate’s direct manager only. |
Return value: 1 if true, 0 if false.
Examples
The following examples illustrate how you can use PSLang expressions when defining user classes:
Get a user’s first name and store it in a variable for later use:
var $fname = getUserAttrValueFirst( $USERID, "FIRST_NAME" )
Check if a user is in the Accounting group on target system ADCAN:
isGroupMember( $USERID, "ADCAN", "CN=Accounting,OU=Groups,DC=mtdemo,DC=com" )
Check if a subordinate reports directly to a manager:
reportsTo ( $RECIPIENT, $REQUESTER, 1)
Examples 1 and 2 apply to personal user classes. Example 3 applies to relational user classes.
See also
The PSLang Manual ( pslang.pdf ) has more detail about the PSLang language.