User classes

A user class policy is a point within Bravura Security Fabric where user classes can be utilized to define a group of users. This can sometimes remove the need for writing complicated scripts.

The user class policies available within Bravura Security Fabric are:

Requirements

Before you add a user class:

Navigation steps

Use the Select a user class page to add and configure user classes. To navigate to this page:

Click below to view a demonstration using Policies > User classes to review participants and define criteria for the built-in _GLOBAL_HELP_DESK_ user class for help desk users that have privileges allowing them to assist others within the product.

Click below to view a demonstration of creating a user class via the Policies > User classes menu, including: adding a new user class, specifying participants, defining group membership criteria, testing resultant users and then refining the participant list by adding attribute criteria.

To add a user class:

Next

Specify user class 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.

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 )

#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()

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:

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:

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:

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 .

Personal user classes, which have only one participant, allow you to specify explicit users.

Explicit users are included in the user class regardless of the user class criteria.

To select explicit users:

Explicit users can also be removed from a class on this page.

A two-participant relationship user class would allow group owners (for example, team Managers) to provide help desk duties for their group members (for example DirectSubordinate). Those two relationship endpoints (Manager and DirectSubordinate) would be the participants of the class.

With such a configuration, when managers log in and use the Help user link, they would have access to only the employees in their own group.

That user class could be used to provide access of managers to provide help desk duties to their direct employees in Manage the system> Security> Access to user profiles> Delegated administration rules.

The same user class can control profile visibility: configured in a user-class-based user filter like GENERATE_USER_PLUGIN (for specifying who should be managed) or the reverse, FILTER_USER_PLUGIN (to specify who should not be managed) Both plug-in points are in Manage the system> Modules> Options.

The security rule provides access, while the user filter plugin provides visibility.

So if the user class is used in the security rule, but not in the user filter, all profiles would be listed for everyone, but the managers would have access to see only the details of their own employees.

In practice, managers are usually too busy to help their employees with their self-service or approval functionality provided by Bravura Security Fabric , so most of the time there would be specific help desk teams in specific regions working the same time zones as the employees they are supposed to help, and the class relationship would be based on the city or region attribute, with a three-participant user class.

Do not use two-participant classes with PSLang expressions that check on attributes for these use cases. Even though it is feasible for small companies, and easier to configure than writing plugin scripts or three-participant classes, the performance would be impacted during auto discovery and during use the product, such as display of the list of users who can be helped by the viewer and using help desk features.

This configuration example demonstrates the use case where a company wants to provide permissions to reset user passwords without requiring authentication to users in the IT-HELPDESK-MANAGERS and HR-MANAGERS Active Directory groups. A user from EITHER of these Active Directory groups will be granted this permission. Therefore, a user group must be configured with the required privilege and allow membership from ANY assigned user classes.

The built-in HELP_DESK_MANAGER user group already has the required privileges to bypass authentication to reset user passwords. To assign user classes to the user group, we must add the IT-HELPDESK-MANAGERS and HR-MANAGERS AD groups to separate user classes.

This use case assumes an Active Directory target called AD has been configured and has both the IT-HELPDESK-MANAGERS and HR-MANAGERS groups managed.

Add IT-HELPDESK-MANAGERS AD group to the built-in _HELP_DESK_MANAGERS_ user class

Users have been successfully added as members to the _HELP_DESK_MANAGERS_ user class.

Add HR-MANAGERS AD group to a created HR-MANAGERS user class

Now we need to define and add a user class for the HR-MANAGERS active directory group.

Users have been successfully added as members to the HR_MANAGERS user class.

Assign both user classes to the HELP_DESK_MANAGER user group

Through this configuration, permission to reset user passwords without requiring authentication has now been given to users in the IT-HELPDESK-MANAGERS and HR-MANAGERS Active Directory groups.

You can edit user classes by:

Default user classes should be edited during the initial Bravura Security Fabric setup and configuration. For example, define membership and assign user access rules to the _GLOBAL_HELP_DESK_ and _HELP_DESK_MANAGERS_ user classes to create a user base that can help regular users.

There are restrictions to what type of changes you can make to a user class, limited by which policies have that user class in use. See the table below for details.

The product administrator doing the editing must have the "Manage policies" administrative privilege.

You can remove or edit the definition of a user class as long as it has not been used in a certification campaign. If a user class has dependents, such as plugin points, it cannot be removed.

For auditing purposes, a user class cannot be deleted or changed after it has been used. A “used” user class is indicated by the following fields on the User class definition page:

Once the criteria for a user class is defined, you can use the Test membership page to see if a specific User IDs matches the criteria, or to list the User IDs for the members of a user class.

User classes can be cached to improve performance for complex user classes and user class points.

On the General tab for a user class definition, there is an option to Recalculate or Invalidate the user class cache. Membership cache valid indicates the current status of the cache Yes or No.

If the status is Yes, then the user class is cached on the time indicated by Date membership cache last updated. Users that are a member of the user class when it is cached will remain members until the cache expires or is recalculated. Even if the member’s criteria changes, the profile will be considered a member until either recalculation is performed or no longer valid. When there is a cached user class then Invalidate and Recalculate are available.

If the status is No, then the user class has no cached information. Only Recalculate is available to load the cache information.

Only single-participant user class points can be cached. Built-in user classes cannot be changed and cached. This includes:

These are directly evaluated and do not require caching.

User class points that include only built-in user classes do not require any options to cache them. Adding one or more user classes that are not built-in will allow caching to be calculated. When recalculating a user class, any dependent user class points that are cached are also recalculated.

The user class cache expiry time is set by the USERCLASS CACHE EXPIRY variable at Manage the system > Policies > Options. Default is 72 hours.

The psupdate program runs loaduccache at the end of the auto discovery process.

See Event Actions for more information about event configuration.

User class definitions can be added to the following plugin points:

These plugin points include the Use user classes option, which allows you to filter or generate lists of users based on user user classes.

If you choose to use user classes, then you do not need to write a plugin. However, user classes can also be used in conjunction with a plugin.

For example, if you:

To configure the Use user classes option:

This can be set so that: