Skip to main content

Specifying participants

Each user class requires at least one participant. Relational user classes require at least two.

The Participants tab of the User class definition pages defines the meaning of the user class, not necessarily the profile "members" of the user class.

  • A one-participant class, or personal user class, is just a flat list of user profiles; for example: product administrators , or help desk users who can manage everyone in the system, or (for Identity or Privilege) catch-all managers who can approve requests for everyone in the system.

    You can add segments of users or explicit users to a personal user class.

  • A two-participant class is a direct relationship; for example: a manager and their direct subordinates, a group owner and its group members, an approver and the user profiles whose requests he is assigned to approve, a site manager and all employees at that site, and so on.

    See Example: Segregating help desk privileges .

  • A three-participant, or multiple-participant are much more esoteric relationships, in which some of the "participants" change the relationship between the other participants; for example: a manager of a specific type over a set of employees (HR manager, Site manager, Direct manager, and so on), the type being the third "Participant" in the relationship, based on which specific privileges can be granted to manager over employees, or vice-versa.

Single-participant user class membership is cached at the end of the auto discovery process (psupdate) , so when they are used to display segments of the Profile lists in the WebUI, they are faster.

Multi-participant user classes are not cached, so their criteria are evaluated on-the fly when the user class is used (similar to script-driven plugin points )

Adding a new participant specification

If you have just added a new user class, the Participant specification page loads automatically. Skip to Step 4 in the following procedure. To add a participant for an existing user class:

  1. Navigate to the User class definition page.

  2. Click the Participants tab.

  3. Click Add new… if Bravura Security Fabric displays a list of existing participants.

    The page is displayed by default if there are no defined participants.

  4. Type an ID and Description to identify the participant. The ID is used to differentiate participants in relational user classes; for example, “Recipient” and “Requester”. In personal user classes, ID is simply a placeholder. For consistency with the default personal user classes, type USERID.

  5. If you want to restrict user listing, then see Using list expressions for details on the Listing members option.

  6. Click Add.

Next

  • If you are defining a relational user class, click Add new… to add another participant, which returns you to step 4.

    or

  • Define user class criteria .

Modifying a participant specification

To modify an existing participant specification:

  1. Navigate to the User class definition page.

  2. Click the Participants tab to view the Participant criteria page.

  3. Select the participant you want to view or modify.

  4. Modify the Description if required.

  5. If you are modifying a user class list point and want to restrict user listing, then see Using list expressions for details on the Listing members option.

  6. Click Update.

Using list expressions

The Listing members function allows you to modify the default listing behavior for a user class. This optional function is only relevant to user class list points using PSLang criteria. The default listing behavior lists all users and every single user is tested for membership. This may be cumbersome and unnecessary, and a listing expression may be more efficient.

For example:

"Is <User> a manager of JohnB?” This PSLang criteria is defined by a simple expression. The default listing behavior would list and individually test every single user, which could take a long time. However, writing a List expression to simply answer the question "Who is JohnB’s manager?” is much more efficient. The List expression outputs a shortlist that is filtered by the user class criteria.

Exclusive and non-exclusive listing

The Listing members function can be used for either exclusive or non-exclusive listings. Exclusive listings simply run the List expression, and the users in the resulting shortlist automatically become members of the user class. Non-exclusive listings run the List expression and then filter the returned users through the other user class criteria. They are filtered through the attribute and membership criteria first, and the resulting list is then filtered through the PSLang criteria.

The listing type is defined by the Participants match this class solely via membership in this list (other criteria not considered) option. If this option is:

  • Enabled then the List expression is exclusive and the users that are output by the expression automatically become members of the user class.

  • Disabled then the List expression is non-exclusive and the users that are output by the expression are filtered through all additional user class criteria.

Caution

When writing a PSLang expression for the Listing members function, you must ensure that the list expression is compatible with the PSLang criteria expression. If the list expression does not return the same users that the PSLang criteria allows, then any user class policies affected by this user class will behave inconsistently.

Configuring the list expression

Configure the Listing members function from the Participant specification page.

To use a list expression:

  1. Enable the Use the list expression checkbox.

  2. Type the PSLang List expression into the text field.

  3. If you want to exclude other criteria, enable Participants match this class solely via membership in this list.

  4. Click Add if you are adding a new participant, or click Update if you are modifying an existing participant.

List expression example

The list expression should be a PSLang expression that invokes the USERCLASSUSERFOUND() function once for each profile ID to include in the class. If it needs to obtain the profile IDs from another source, it is recommended to do so in a loop as per the following example.

#Example: Include all users that have an account on the target "AD_HELPDESK_USERS":
#
function fn() {
    var $arr = getUsersByTarget("AD_HELPDESK_USERS");
    for(var $i=0; $i < size($arr); $i++) {
        UserclassUserFound( $arr[$i] );
    };
    return 0;
} 
fn()

See also

See more information on writing PSLang expressions .

In this section: