Conditions in conditional flows

As was mentioned in Execution requirements, _Condition executions can be only contained in Conditional subflow. If all Condition executions evaluate as true, then the Conditional sub-flow acts as Required. You can process the next execution in the Conditional sub-flow. If some executions included in the Conditional sub-flow evaluate as false, then the whole sub-flow is considered as Disabled.

Available conditions

Condition - User Role

This execution has the ability to determine if the user has a role defined by User role field. If the user has the required role, the execution is considered as true and other executions are evaluated. The administrator has to define the following fields:

Alias: Describes a name of the execution, which will be shown in the authentication flow.
User role: Role the user should have to execute this flow. To specify an application role the syntax is appname.approle (for example myapp.myrole).

Condition - User Configured

This checks if the other executions in the flow are configured for the user. The Execution requirements section includes an example of the OTP form.

Condition - User Attribute

This checks if the user has set up the required attribute. There is a possibility to negate output, which means the user should not have the attribute. The User Attributes section shows how to add a custom attribute. You can provide these fields:

Alias: Describes a name of the execution, which will be shown in the authentication flow.
Attribute name: Name of the attribute to check.
Expected attribute value: Expected value in the attribute.
Negate output: You can negate the output. In other words, the attribute should not be present.

Explicitly deny/allow access in conditional flows

You can allow or deny access to resources in a conditional flow. The two authenticators Deny Access and Allow Access control access to the resources by conditions.

Allow Access

Authenticator will always successfully authenticate. This authenticator is not configurable.

Deny Access

Access will always be denied. You can define an error message, which will be shown to the user. You can provide these fields:

Alias: Describes a name of the execution, which will be shown in the authentication flow.
Error message: Error message which will be shown to the user. The error message could be provided as a particular message or as a property in order to use it with localization. (i.e "You do not have the role 'admin'.", my-property-deny in messages properties) Leave blank for the default message defined as property access-denied.

Here is an example how to deny access to all users who do not have the role role1 and show an error message defined by a property deny-role1. This example includes Condition - User Role and Deny Access executions.

Browser flow

Deny access flow

Condition - user role configuration

Deny access role settings

Configuration of the Deny Access is really easy. You can specify an arbitrary Alias and required message like this:

Deny access execution settings

The last thing is defining the property with an error message in the login theme messages_en.properties (for English):

deny-role1 = You do not have required role!