User filters

Modified on Mon, 27 Oct at 5:12 PM

Contents

Creating user filters
- Filter configuration
Authorization configuration
Editing / deleting user filters

Creating user filters

Creating a user filter to assign authorization to a group of people within the client.

To create a user filter, click on Create user filter.

Name

The name to give to this user filter.

Description

An optional description for the user filter.

The login service for which the fitler is to be created. Only for users who log in via the selected login service does this user filter and thus the configured authorization within the client take effect. The login service determines how the filter is to be configured. See Filter configuration.

Filter type

Specifies the type of the filter. The filter type determines how it is to be configured. See Filter configuration. The filter type is selectable only for login services of type LDAP and Kerberos.

Filter configuration

There are three types of user filters by default:

LDAP filter

LDAP filters can be configured only for LDAP and Kerberos type login services. For LDAP filters, a user search request is made to the LDAP server based on the configured filter. The following information is required for the configuration of:

BaseDN: Represents the root to search for user objects on the LDAP server.
Filter-Abfrage: an optional filter query to apply further restrictions within the set of user objects of the LDAP server (Tutorial)

The Group search button lists all groups available on the LDAP server within the given BaseDN. This list can be further filtered via the search field and with a click on an entry the filter query is preset.

Configuration of an LDAP user filter by using the group search.

Only users, the LDAP filter applies to, are assigned to this user configuration and thus to the authorization within the client.

LDAP filters behave the same way as LDAP groups from previous formcycle versions.

Profile condition

This filter type is available for all login services including plugin login services. Here, multiple conditions can be defined on properties of the user profile and how these conditions should be logically linked. The properties of the logged in user profile are available as a JSON structure. To check properties, the JSON path to them is selected (see Conditions below).

Connection: the connection specifies how the configured individual conditions are to be logically linked to each other. Three options are available:
- All must apply (AND): All configured conditions must apply in order for the logged-in user to be assigned this user configuration and thus authorization within the client.
- One or more must apply (OR): At least one of the configured conditions must apply in order for the logged-in user to be assigned this user configuration and thus authorization within the client.
- User-defined connection: For complicated cases, this option allows one to enter any logical links of the configured conditions. By default, the conditions are evaluated from left to right. By using brackets, the order of evaluation can also be influenced. The conditions to be used must be inserted as follows:
  - cN: A condition, for example c1 or c3. The names of the conditions are always in the heading of the condition. For a better overview, the names of the conditions can also be changed by clicking on them.
  - not: negation, which must precede the value to be negated. For example:
    - c1 and not c2
    - c1 or not (c2 and c3)
  - and: AND operation, which is true if both concatenated values are true. For example:
    - c1 and c2
    - c1 and not c2 and c3
  - or: OR operation, which is true if one of the two concatenated values is true. For example:
    - c1 or c2
    - c1 or c2 or not c3
  - false, true: These two constants represent the logical values false and true.
  - xor, nand, nor, implies, impliedby, equiv, unequiv: Represents, in this order, the logical operators Contravalence, Alternative Negation, Common Negation, Material Implication, Opposite Implication, Material Equivalence, and Nonequivalence.
Conditions: Any number of conditions can be specified. A condition can check exactly one profile property.
- JSON path to the property
  The JSON path selects a property of the profile and thus a part of the JSON object that represents the profile of the logged in user. A condition can then be checked on this property/part of the JSON object. The selected property can take different forms, namely all valid JSON data types:
  - String: A sequence of characters that represents a testable property.
  - Number: A number that represents a testable property.
  - Object (JSON object): represents a complex property of the profile. As a rule, no condition can be meaningfully checked for JSON objects. So the JSON path should be extended to select a testable sub-property of the object.
  - Array: a set of additional elements / properties. The elements of the array can be any of the valid JSON data types. As a rule, however, testing only makes sense with arrays whose elements are of type String, Number or Boolean. If this is not the case, then the JSON path should be refined to select a testable attribute. For arrays, usually only the conditions Empty, Not empty, Contains and Does not contain can be used meaningfully.
  - Boolean: can have the value true or false and represents a testable property.
- Condition: Condition to test. The following options are available for selection:
  - empty
  - not empty
  - equal
  - not equal
  - contains
  - does not contain
  - greater than
  - greater than or equal to
  - less than
  - less than or equal to
  - starts with
  - does not start with
  - ends with
  - does not end with
  - matches regexp
  - does not match regexp
- Value to compare ageainst: The value of the selected condition used for the check. Visible if Empty or Not Empty is not selected as the condition.

Please note that certain conditions must be used for certain constellations. For example, when comparing with an array, the ‘Contains’ condition must be used instead of the ‘Equal’ condition, even if there is only one element in the array.

Configuration of a user filter via two AND connected profile conditions. In this example, all users are assigned to this user configuration who are part of the group "Clerk" (memberOf) and in the organistaion "Demo AG " (organisation).

Only users whose profiles match the individual conditions ind the selected link are assigned to this user configuration and thus to the authorization within the client.

Examples of filter configurations

The following examples are intended to check whether you belong to a group with a specific name. The check is carried out using JSON path notation.

Example data from a Microsoft Entra ID (e. g. with OIDC) login:

Example data from a user login with Microsoft Entra ID

Filter configuration for checking group membership (memberOf) in the group with name (displayName) "internal-users".

Example data from a Microsoft Active Directory login:

Example data from a user login to a Microsoft Active Directory

Filter configuration for checking group membership (memberOf) to the group named "Internal-Users". It is important to ensure that the complete path to the AD group is specified as the comparison value.

Microsoft Entra ID filter

Microsoft Entra ID filters can only be configured by Microsoft Entra ID login services. The Entra ID filter is very similar to profile conditions and can also be configured in the same way as profile conditions by specifying conditions on JSON paths. However, in addition, it is possible to define conditions on known properties of Entra ID profiles:

User groups: This profile property represents the list of user groups of which the user is a member. When this property is selected, suggestions of existing user groups appear in the comparison value field. This profile property is available only if the selected Microsoft Entra ID login service has the "Query full group information" option enabled. In addition, the Group.Read.All application permission must be granted in order for formcycle to make suggestions based on the Entra ID tenant's user groups.

Grant the application permission Group.Read.All via Entra ID Admin Center to allow formcycle to make suggestions based on Entra ID tenant user groups.

Manager: This profile property represents the manager of the user. When this property is selected, suggestions of existing users appear in the comparison value field. This profile property is available only if the selected Microsoft Entra ID login service has the "Query manager" option enabled. Also, the User.Read.All application permission must be granted for formcycle to make suggestions based on Entra ID tenant users.

Granting the User.Read.All application permission via the Entra ID Admin Center to allow formcycle to make manager suggestions based on Entra ID tenant users.

Configuration of an Entra ID user filter using two AND connected profile conditions. In this example, all users are assigned to this user configuration that are part of the formcycle users and Departement C user group.

Plugin filter

It is also possible that plugin login services provide additional user filter extensions.

Testing user configurations:

User configurations and their set conditions (profile conditions, Entra ID) or filters (LDAP filters) can be tested with a user login by clicking the "Test user configuration" button. After clicking the button, a prompt for entering a user login appears. After successful login, the profile information of the user is displayed in JSON form and above it, whether the authorization of this user configuration was successful or not, i.e. whether the selected conditions / filters are effective for the user or not.

Test result of a user configuration with successful authorization result.

Authorization configuration

The configuration of authorization within formcycle is described in the article Users under Authorization Configuration. Please also note the following information:

For user filters, role selection is not available if the selected login service has not been configured for the management interface.

Editing / deleting user filters

User filters with client admin role:

Editing: Can be edited only by the SAdmin or users with the role permissionEdit administrators.
Deleting: Can be deleted only by the SAdmin or users with the role permission Edit administrators.

User filters without client admin role:

Editing: Can always be edited.
Deleting: Can always be deleted.